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j  abstract 

\ 

^This  thesis  presents  the  design  and  implementation  of  a 
software  protocol  for  the  7AX-1 1/780,  under. the  VMS  oper¬ 
ating  systea,  to  allow  message  and  file  transfer  to  and  from 
the  IHTE1IEC  HDS  systea,  under  CP/H-80  operating  system,  via 
the  Ethernet  local  area  network. 

The  design  of  this  software  protocol  is  based  on  the 
protocol  hierarchies  where  the  network  is  organized  as  a 
series  of  layers  or  levels,  each  one  build  upon  its  prede¬ 
cessor.  The  purpose  of  each  layer  is  to  offer  certain 
services  to  the  higher  layers,  shielding  those  layers  from 
the  details  of  hew  the  offered  services  are  actually 
iapleaented. 

with  this  design  concept,  the  desired  software  protocol 
will  be  transportable  in  the  sense  that  it  can  be  used  by 
different  kinds  of  coaputer  systems  with  ainiaal 
aodif  ications. 

The  Ethernet  local  area  network  is  also  designed  in  this 
same  highly  structured  way^ 
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I*  IITBOPOCTIOH 


1.  BISCLAIBER 

Ban;  ter  as  used  in  this  thesis  are  registered  trademarks 
of  coaaercial  products.  Rather  than  atteapt  to  cite  each 
individual  occurrence  of  a  trademark,  all  registered  trade- 
marks  appearing  in  this  thesis  will  be  listed  below, 
following  the  firm  holding  the  trademark: 

INTEL  Corporation,  Santa  Clara,  California 
IN  TELL  EC  BOS 
flultibus 

DIGITAL  Research,  Pacific  Grove,  California 
CE/B-80 

INTEBLAN  Corporation,  Chelmsford,  Massachusetts 

H1 10 1 0  Onifcus  Ethernet  communications  controller 
beard 

NI3010  flultibus  Ethernet  communications  controller 
beard 

NS2030  VHS  device  driver  and  Nil 010  diagnostic 
program 

DIGITAL  Equipment  Corporation,  Haynard,  Massachusetts 
VAX- 11/780  Mini  computer 
VAX/VMS  operating  system 

B.  GEBEBAL  DXSCOSSICH 

This  thesis  presents  the  design  and  implementation  of 
software  protocol  for  the  VAX-11/780,  under  VMS  operating 
system,  to  allow  message  and  file  transfer  to  and  from 
IHTELLEC  BDS  system,  under  CP/H-80  operating  system,  via 
ftherne  local  t  :ea  network . 
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The  Ethernet  board  is  the  product  of  Interlan  company 
which  has  produced  the  hardware  and  software  technology 
needed  tc  connect  several  makes  of  computers  to  the  network. 
All  ccamunications  between  host  computers  are  made  through  a 
coaxial  cable  which  has  a  10  megabit  per  second  data  commu¬ 
nications  rate.  The  Ethernet  design  is  based  on  a  highly 
structured  protocol  where  the  network  is  organized  as  a 
series  of  layers  or  levels,  each  one  build  upon  its  prede¬ 
cessor.  The  purpose  of  each  layer  is  to  offer  certain 
services  to  the  higher  layers,  shielding  those  layers  from 
the  details  cf  hew  the  offered  services  are  actually  imple¬ 
mented. 

This  concept  of  design  yields  a  lot  of  advantages  in 
developing  software  protocol  such  that  it  can  be  used  by 
different  computer  systems  with  the  minimum  of  modifica¬ 
tions.  It  is  anticipated  that  the  software  protocol  designed 
will  be  general  in  nature  in  order  to  be  used  with  ether 
computers  using  different  operating  systems  with  minor 
changes.  The  specific  goals  of  this  thesis  are  discussed  in 
the  next  section  concerning  the  background  of  the  project. 

C.  BACKGBOUND 

The  AEGIS  weapons  system  simulation  project  currently 
being  conducted  at  the  Naval  Postgraduate  School  is 
attempting  to  determine  the  feasibility  of  replacing  the 
larger  and  relatively  expensive  main  frame  computer,  the 
AN/UYK-7,  with  a  system  of  16  or  32  bit  micro  computers. 
Several  significant  real-time  functions  of  the  AEGIS  weapons 
system  are  to  be  duplicated  with  associated  data,  inputs, 
timing,  and  supporting  function  so  that  a  rest  example  can 
be  examined  whose  performance  emulates  that  of  th6  actual 
system.  (Bef.  1.] 


Since  the  AEGIS  weapons  system  simulation  project 
involves  eany  micro  computers  and  since  all  of  them  must  be 
real-time  system,  the  speed  of  data  communications  between 
any  two  computers  is  very  crucial.  Thus,  a  high-speed  means 
of  communication  is  needed. 

Ethernet  local  area  network  is  considered  to  be  the 
solution  because  of  its  capability  of  permitting  10  megabit 
per  second  data  communications  between  stations  separated  by 
up  to  25C0  meters.  Two  NI3010  Multibus  Ethernet  communica¬ 
tion  controller  boards  and  a  NI1010  Onibus  Ethernet  communi¬ 
cation  controller  beards  were  purchased  and  implemented  in 
IHTEIIEC  BDS  systems  and  VAX-11/780,  under  the  VMS  operating 
system,  respectively.  An  WS2030  device  driver  and  an  NI1010 
diagnostic  program  are  also  implemented  in  the  VAX. 

The  specific  goals  of  this  thesis  are: 

1 . To  design  and  implement  software  protocol  on  the 
VAX/VMS  such  that  it  would  be  able  to  communicate  (transfer 
messages  and  files)  with  the  XNTELLEC  fl DS  system,  under  the 
CP/M  operating  system. 

2.  To  be  used  as  a  guideline  in  designing  software 
protocols,  especially  when  there  is  a  need  to  communicate 
between  VAX/VMS  and  ether  systems  which  use  different  oper¬ 
ating  systems  such  as  ISIS-II. 

0.  STB0CT0BE  OF  THE  THESIS 

Chapter  I  presents  a  general  discussion  of  the  larger, 
ongoing  effert  of  which  this  thesis  is  a  part.  It  also  gives 
a  general  discussion  of  the  background  work  of  the  AEGIS 
weapons  system  simulation  project  and  the  need  of  the 
Ethernet  local  area  network  which  leads  to  this  thesis 
research. 


Chapter  n  addresses  the  overall  design  philosophy  of 
the  software  protocol  which  will  be  used  in  the  VAX/vas. 
Protocol  for  a  local  area  network  is  discussed  in  detail  to 
include  the  relationship  to  the  ISO  open  system  interconnec¬ 
tion  model.  The  design  issues  for  the  layers  are  enumerated 
to  be  a  step-by-step  guide  in  designing  the  protocol. 

Chapter  III  discusses  the  Ethernet  Local  Area  Network, 
concise  Ithrnet  specification.  and  the  NI1010  Onibus 
Ethernet  Controller  Beard. 

Chapter  IV  explains  the  detailed  design  of  the  software 
protcccl  to  include  the  use  of  the  NS2Q30  Device  Driver,  how 
Ethernet  Eoard  and  the  Device  Driver  take  care  of  the  design 
issues  fer  the  layer  mentioned  in  Chapter  II,  and  steps  in 
developing  the  application  layer  protocol. 

Chapter  V  summarizes  the  testing  of  the  implemented 
software  protocol  and  describe  its  capabilities.  Suggestions 
are  also  given  fer  future  research  and  modification. 


II.  BASIC  DESIGH  CONCEPTS 


A.  EBCTCCOL  P08  LOCAL  ABBA  HETBORK 
1 .  Background 

A  set  of  protocols  specifies  how  nodes  can  communi¬ 
cate  ever  networks.  Frctocols  are  the  procedures  and  conven¬ 
tions  used  to  regiment  the  event  progression  required  for 
orderly,  mutually  understood  interaction  between  processes. 
Protocols  are  developed  to  satisfy  qualitative  and  quantita¬ 
tive  requirements  for  process  interconnection.  A  primary 
qualitative  requirement  is  the  Nuseful"  work  (i.e.,  func¬ 
tionally)  to  be  provided  by  the  protocol.  Other  qualitative 
requirements  include: 

a)  .flexibility  (to  accommodate  new  uses  and  features) 

b)  .completeness  (to  properly  respond  to  all  relevant 

network  conditions) 

c)  .deadlock  avoidance/backout  mechanisms 

d)  .synchronization  mechanisms  (for  interprocess  control) 

e)  .error  detection  and  recovery 

f) . buffer  overflow  avoidance 

g)  . message  sequencing  assurance 

h) . duplicate  message  detection  and  recovery 

i)  . permeance  (to  implement  the  protocol  uniformly  through 

the  local  area  network) 
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j) . priority  mechanisms 

k)  .accounting  mechanisms 


13 


1)  .security  mechanisms 

a)  .  aessage  delivery  guarantees 

n) .data  ccde/fcraat  transformations 

o)  .computer  equipaent  feature  coapa tibility 

p)  .operating  systea  feature  coapatibility 

q)  .ccmaunica ticns  network  feature  coapatibility 

Net  all  of  these  requirements  are  of  equal  impor¬ 
tance  for  each  protocol  i apleaentation.  Por  example,  a 
protocol  might  inhabit  a  local  area  network  node  environment 
configured  into  any  of  the  following  topologies  or  hybrids 
of  these  topologies: 

a)  .star  topology  -  a  centralized  topology  in  which  lines 

converge  to  a  central  point  or  points  (see  Pigure 
2. 1)  ;this  topolcgy  is  also  called  .  ierarchical  or  tree. 

b) .aesh  topology  -  nodes  are  connected  in  an  arbitrary 

pattern;  each  node  can  have  multiple  paths  to  ether 
nodes. 

c)  .ring  topology  -  the  communications  path  is  a  loop  with 

each  node  connected  to  exactly  two  other  nodes  in  a 
given  loop. 

d)  .bus  topology  -  the  nodes  are  connected  along  line 

segments;  this  topology  is  commonly  found  in  Local  area 
networks  with  a  shared  transmission  channel  such  as  a 
cable-bus. 

Typically,  routing  protocols  for  mesh  topologies  are  much 
acre  complex  than  routing  protocols  for  the  other  topolo¬ 
gies.  Thus,  other  protocol  requirements,  such  as  message 
delivery  guarantees  and  message  sequencing  assurance,  may  be 
influenced  by  the  topology  chosen. 


Figure  2.1  local  Area  latvork  Topologies. 


|  Quantitative  requireaents  for  protocols  include: 

;i  a)  throughput  -  the  voluae  of  inforaation  that  bust  be 

\  transferred  during  the  peak  period.  This  vcluae  is 

S  usually  characterized  by  aean  aessage  length  in  octets, 

the  distribution  of  aessage  lengths,  and  by  the  arrival 
£  rate  cf  sassages. 
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b)  delay  -  the  mean  and  aaxinua  delay  that  the  protocol 
will  add  to  process  responsiveness  during  the  peak 
period. 

c)  ccst  -  aaxiaua  acceptable  recurring  and  nonrecurring 
costs  associated  with  the  installation  of  a  protocol  in 
a  local  area  network. 

A  protocol  aay  perfora  functions  at  the  comaunica- 
tion  link  level  or  at  application  process  level.  Of  priaary 
concern  tc  local  area  network  application  developers  are  the 
application  level  protocols,  soae  of  the  protocols  which 
aight  be  considered  eleaentary  to  local  area  network  devel- 
opaents  are  discussed  below. 

2.  AlBii&aligfl  sub  sy  slew  perspective  of 

BlStogo I5 

The  need  fcr  a  nuaber  of  eleaentary  high-level 
protocols  providing  various  types  of  services  is  apparent. 
Three  aain  groupings  of  such  protocols  aay  be  defined: 
applicaticn-oriented ,  executive-oriented,  and  network- 
induced.  The  aotivation  for  this  classification  is  the 
perspective  of  distributed  systeas  as  extensions  of  the 
single-systea  environaent.  The  goal  of  eleaentary  protocols 
is  to  extend  the  array  of  systea  utilities,  programs  and 
operating  systea  services  that  are  available  on  a  single 
systea  to  the  total  lccal  area  network.  Hence,  developaent 
of  eleaentary  local  area  network  protocols  is  a  basic  step 
in  evolving  high-level  operating  systems  for  local  area 
networks. 

a.  Applicaticn-Oriented  Protocols 

Applicaticn-oriented  protocols  are  defined  to  be 
interprocess  coaaunication  rules  and  data  foraats  which 
extend  the  coaaonly  used  systea  programs  (languages, 
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editors*  library*  etc.)  of  one  node  to  an  application 
process  in  another  node,  such  protocols  say  include: 

1)  .lils  Transfer  -  allowing  a  process  in  one  node  to 

access  files  on  another  node  as  though  the  process  were 
executing  in  that  node.  Sisilar  to  general  system  util* 
ities  that  support  media  conversion  with  and  without 
blocking  changes*  format  changes*  naming  changes* 
etcetera. 

2)  . fditcr  -  allowing  a  process  in  one  node  to  store, 

■edify  and  retrieve  text  information  in  a  file  at 
another  node.  Preferably  the  protocol  is  implemented  to 
a  specification  consistently  applied  at  each  node  on 
the  network. 

2) . Compile  *  allowing  a  process  in  one  node  to  produce 
executable  pregrass  at  another  node.  The  protocol 
itplements  a  network  wide  source  and  object  code 
library  and  linkage  editor. 

4)  .Execute  -  allowing  a  process  in  one  node  to  invoke  a 

program  at  another  node  by  module  name*  to  supply 
parameters  to  the  program  and  to  receive  program  output 
and  system  notice  messages  at  the  sending  local  area 
network  node  process. 

5)  . Depug  *  allowing  a  process  in  one  node  to  dynamically 

debug  a  program  at  another  node.  Preferably  allows  an 
application  process  distributed  among  two  or  more  local 
area  network  nodes  to  be  debugged  interactively. 

b.  Executive-Oriented  Protocols 

Executive  level  protocols  are  defined  to  be 
interprocess  communication  rules  and  data  formats  which 
extend  the  operating  system  services  (resource  allocation* 
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device  cr  program  service,  monitor  services,  etc.)  of  one 
node  to  an  application  process  in  another  node. 

1)  . Coeeand  Prctoccl  -  allowing  coaaonly  used  operating 

system  services  (ASSIGN,  print,  TIRE,  STATUS,  etc.)  in 
each  node  cf  a  network  to  be  invoked  uniformly  by  a 
process  in  another  node. 

2)  -lillsal  £££211122  Ssiaiaal  ££212 sal  ‘  allowing  a 

process  in  one  node  tc  communicate  with  a  process  in 
another  node  as  though  the  receiving  process  were  a 
scrolling  output  device  such  as  a  printer  or  teletype. 

3)  -IlllJial  Screen  Terminal  Protocol  -  allowing  a  process 

in  one  node  to  communicate  with  a  process  in  another 
node  where  the  receiving  process  operates  on  a  randomly 
addressable  collection  of  two  dimensional  pages  of  text 
using  predefined  functions  and  transmitted  variables. 

<0  *l±£t£al  itafik 3S£2l£2l  ££212221  *  allowing  a  process 

in  cne  node  to  communicate  with  a  process  in  another 
node  whore  the  receiving  process  operates  on  a  randomly 
addressable  collection  of  two  or  three  dimensional 
figures  and  two  dimensional  text  using  predefined  func¬ 
tions  and  transmitted  variables. 

c.  Net  work- Induced  Protocols 

Network  induced  protocols  are  defined  to  be 
interprocess  communication  rules  and  data  formats  which 
facilitate  the  operation  of  executive  level  and  application 
level  protocols  in  a  local  area  network. 

1)  -SSllSli  &a&£2lll  Esslaialisa  ££212221  -  provides  the 

mechanism  fcr  a  local  area  network  node  to  establish  or 
disestablish  addressable  network  ports  in  a  directory 
thereby  allowing  qualified  processes  in  other  nodes  to 


become  associated  with  processes  assigned  to  this  port. 
The  protocol  night  serve  noraal  and  previleged 
processes  in  the  application  space  as  well  as  network 
control  functions  within  the  operating  system.  This 
prctocol  provides  a  mechanism  to  identify  "well  known" 
processes  in  a  network  directory. 

2)  .  Network  Access  Authorization  Protocol  -  allowing  a 

precs'ss  to  gain  access  to  another  process  in  the 
network.  Includes  log-on/log-off  support  to  end  users 
as  well  as  general  process  interconnection  authoriza¬ 
tion.  Interfaced  with  network  security  and  privacy 
management  information  systems. 

3)  . Network  Directory  Service  Protocol  -  allowing  a  process 

to  reguest  information  about  a  node,  another  process  or 
an  end  user.  Hay  also  support  custom  menu  services  for 
each  network  user  to  promote  the  impression  of  a  single 
integrated  system. 

4)  .Transport  Control  Pyotocoj,  -  allowing  a  process  in  one 

node  to  establish  an  association  with  a  process  in 
another  node  and  to  exchange  messages  in  a  virtual 
circuit  or  datagram  mode.  Usually  implemented  as  an 
augmentation  to  the  operating  system  of  a  network  node. 

5)  •  Synchronization  -  providing  a  mechanism 

fer  two  or  more  processes  in  two  or  more  nodes  to  coor¬ 
dinate  asynchronously  executing  functions.  This 
protocol  could  underlie  the  virtual  terminal  control 
protocol. 

6)  « network  System  Cgntyoj  Protocol  -  providing  the 

mechanism  for  establishing  "built-in"  maintenance  and 
security  subsystems  in  a  local  area  network  environ¬ 
ment.  It  is  envisioned  that  performance,  maintenance 
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and  security  checks  should  permeate  the  local  area 
network  software  as  well  as  hardware  system.  This 
protocol  facilitates  unified  specification  of  perfor¬ 
mance,  aaintenance  and  security  related  functions. 

B.  PBOTCCOL  BXEBABCBIZS 

To  reduce  their  design  complexity,  nost  networks  are 
organized  as  a  series  of  layers  or  levels  as  aentioned 
earlier. 

Layer  n  on  one  aachine  carries  on  a  conversation  with 
layer  n  on  another  aachine.  The  rules  and  conventions  used 
in  this  conversation  are  collectively  known  as  the  layer  n 
protocol,  as  illustrated  in  Fig.  2.2  for  a  seven-layer 
network.  The  entities  cca prising  the  corresponding  layers 
on  different  aachines  are  called  peer  processes.  In  ether 
words,  it  is  the  peer  processes  that  coaaunicate  using 
protocol. 

In  reality,  no  data  are  directly  transferred  frea  layer 
n  on  one  aachine  to  layer  n  on  another  aachine  (except  in 
the  lewest  layer)  .  Instead,  each  layer  passes  data  and 
contrcl  information  to  the  layer  iaaediately  below  it,  until 
the  lowest  layer  is  reached,  It  the  lowest  layer  there  is 
chy^ga^  coaaunication  with  the  other  aachine,  as  opposed  to 
the  v^tual  goaampication  used  by  the  highest  layers.  In 
Fig.  2.2  virtual  coaaunication  is  shown  by  dotted  lines  and 
physical  ccaaunicaticn  by  solid  lines. 

Between  each  pair  of  adjacent  layers  there  is  an  inter¬ 
face.  The  interface  defines  which  priaitive  operations  and 
services  the  lower  layer  offers  to  the  upper  one.  'When 
network  designers  decide  how  aany  layers  to  include  in  a 
network  and  what  each  one  should  do,  one  of  the  most  iapor- 
tant  considerations  is  having  cleanly  defined  intefaces 
between  the  layers.  Having  cleanly  defined  interfaces,  in 
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Figure  2.2  Layers*  Protocols,  and  Interfaces. 


tarn,  requires  that  each  layer  perfora  a  specific  ccllection 
cf  veil  uederstoed  functions.  In  addition  to  ainiaizing  the 
aaount  of  inforaaticn  that  oast  be  passed  between  layers, 
clean  cut  interfaces  also  aake  it  siaplar  to  replace  the 
iapleaentation  of  one  layer  with  a  coapletely  different  one, 
because  all  that  is  required  of  the  new  iapleaentation  is 
that  it  offers  exactly  the  saae  set  of  services  to  its 
upstairs  neighbor  as  the  old  iapleaentation  did. 


The  set  o£  layers  and  protocols  is  called  the  network 
achitactogf  [Bef .  2.  ]-  The  specification  of  the  architec¬ 
ture  aust  contain  enough  intonation  to  allow  an  implementer 
to  write  the  prograe  for  each  layer  so  that  the  program  will 
correctly  obey  the  appropriate  protocol.  Neither  the  details 
of  the  ispleeentaticn  nor  the  specification  of  the  inter¬ 
faces  are  part  of  the  architecture.  In  fact,  it  is  not  even 
necessary  that  the  interfaces  on  all  machines  in  a  network 
be  the  same,  provided  that  each  machine  can  correctly  use 
all  the  protocols. 

C.  DESIGI  ISSUES  FOB  THE  LAYEBS 

Some  of  the  key  design  issues  that  occur  in  computer 
networking  are  present  in  several  layers.  The  following  are 
some  of  the  common  problems  that  aust  be  repeatedly  dealt 
with  in  the  design  of  the  different  protocols. 

1.  Every  layer  aust  have  a  mechanism  for  connection  estab¬ 
lishment.  Since  a  network  normally  has  many  computers, 
some  of  which  have  multiple  processors,  some  means  is 
needed  far  a  process  on  one  machine  to  specify  who  it 
wants  to  talk  to.  In  any  layer  where  there  are  multiple 
destinations,  addressing  is  needed. 

2.  Closely  related  to  the  mechanism  for  establishing 
connections  across  the  network  is  the  mechanism  for 
terminating  them  once  they  are  no  longer  needed. 

3.  Another  set  of  design  decisions  are  the  rules  for  data 
transfer.  Does  data  only  travel  in  one  direction,  called 

communication,  or  can  data  travel  in  either 
direction,  but  not  simultaneously,  called  halj-dupj.es 
communication,  or  can  they  travel  in  both  directions  at 
once,  called  f ull-duplex  communication?  The  protocol 
aust  also  determine  how  many  logical  channels  the 
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connection  corresponds  to*  and  what  their  priorities 
are.  fl any  networks  proride  at  least  two  logical  channels 
Fer  connection,  cne  for  noraal  data  and  one  for  argent 
data. 

4. £rrcr  control  is  an  iaportant  issue  when  the  physical 
coaaunication  circuits  ar9  not  perfect.  Hany  error- 
detecting  and  error-correcting  codes  are  known,  but  both 
ends  of  the  connection  aust  agree  on  which  one  is  being 
used.  In  addition,  the  receiver  aust  have  soae  way  of 
telling  the  sender  which  aessages  have  been  correctly 
received  and  which  have  not. 

5.  Hot  all  coaaunication  channels  preserve  the  order  of 
aessages  sent  on  thea.  To  deal  with  a  possible  loss  of 
sequencing,  the  protocol  aake  explicit  provision  for  the 
receiver  to  allcw  the  pieces  to  be  put  back  together 
properly. 

6.  An  issue  that  cccurs  at  every  level  is  how  to  keep  a 
fast  sender  froa  swaaping  a  slow  receiver  with  data. 
There  are  various  solutions  to  this  and  all  of  then 
involve  soae  kind  of  feedback  froa  the  receiver  tc  the 
sender,  either  directly  or  indirectly,  about  what  the 
receivers  current  situation  is. 

7 .  Another  problea  that  aust  be  solved  repeatedly  at 
different  levels  is  the  inability  of  all  processes  to 
accept  arbitrarily  long  aessages.  This  leads  to  aechan- 
isas  for  disasseabling,  transaitting,  and  then  reassen- 
bling  aessages. 


D.  THE  ISO  BEFBBEICE  BO  DEL 

This  ncdel  is  elcsely  based  on  a  proposal  developed  by 
the  International  standard  Organization  (ISO)  as  a  first 
step  toward  international  standardization  of  the  various 
protocols. 

The  Beference  Bedel  of  Open  Systaa  Interconnection  has 
seven  layers  as  shown  in  Fig.  2.3. 
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The  principles  that  ISO  applied  to  arrive  at  the  sever, 
layers  are  as  follows: 

1.  &  layer  should  be  created  where  a  different 
level  of  abstraction  is  needed. 

2.  Each  layer  should  perfora  a  well  defined 

function. 

3.  The  function  of  each  layer  should  be  chcsen 
with  an  eye  toward  defining  internationally  standardized 
protocols. 

4.  The  layer  boundaries  should  be  chosen  to 
ainiaize  the  imforaation  flow  across  the  interfaces. 

5.  The  number  of  layers  should  be  large  enough 
that  distinct  functions  need  not  be  thrown  together  in  the 
same  layer  cut  of  necessity,  and  small  enough  that  the 
architecture  does  not  become  unwieldy. 

The  seven  layers,  from  the  lowest  layer  to  the  highest 
layer,  are: 

1  .Physical  la ver  -  The  physical  layer  provides 
mechanical,  electrical,  functional  and  procedural 
characteristics  to  establish,  maintain,  and 
release  physical  connections  (e.g.,  data-circuits) 
between  lick-entities.  The  physical  layer  provides 
for  the  transmission  of  transparent  bit  streams 
between  data  link  layer  protocols  across  physical 
connections  which  are  permanently  or  dynamically 
established. 

2»Jfet£  ii&JS  Laver  -  The  purpose  of  the  data  link 
layer  is  tc  provide  the  functional  and  procedural 
means  to  establish,  maintain,  and  release  one  or 
mere  data  links  among  network-entities.  This  layer 


nasks  the  characteristics  of  the  physical  layer 
(such  a3  switched,  multipoint,  broadcast,  polling, 
contention,  etc.)  from  the  network  layer. 

3.  Network  Laver  -  The  network  layer  provides  func¬ 
tional  and  procedural  means  to  exchange  network- 
services-data-uni ts  between  two  transport-entities 
over  a  network-connection.  It  provides  transport- 
entities  with  independence  from  routing  and 
switching  considerations,  including  the  case  where 
a  tandem  subnetwork-connection  is  used.  The 
network  layer  protocol  uses  underlying  data  link 
connections  to  make  network  connections  invisible 
tc  the  transport  layer  protocol. 

4.  Transport  Laver  -  The  transport  layer  exists  to 
provide  a  universal  transport  service  in  associa¬ 
tion  with  the  underlying  services  provided  by 
lower  layers.  The  transport-service  provides 
transparent  transfer  of  data  between  session- 
entities.  The  transport-service  relieves  these 
session-entities  from  any  concern  with  the 
detailed  way  in  which  reliable  and  cpst-effsctive 
transfer  cf  data  is  achieved.  Three  types  of 
transport  services  are: 

-  A  connection-oriented  service 

-  A  transaction-oriented  service 

-  A  broadcast-oriented  service 

The  transport  service  is  required  to  optimize  the 
use  of  the  available  communications  services  to 
provide  the  performance  required  for  each  connec¬ 
tion  between  session-entities  at  a  minimum  cost. 
To  achieve  optimization,  the  global  demands  of  all 
concurrent  transport  users  and  the  transport  layer 
resource  limitations  are  considered. 


5. Session  layer  -  The  purpose  of  the  session  layer 
is  to  assist  in  the  support  of  the  interactions 
between  cocrperating  presentation-entities.  To  do 
rhis,  the  session  layer  provides  services  which 
are  classified  into  the  following  two  categories: 

a) Session  Administration  Services 

binding  two  presentation-entities  into 
a  relationship  and  unbinding  thsa. 

b)  Session  Dialogue  Service  -  control  of 
data  exchange,  delimit  and  synchron¬ 
izing  data  operations  between  two 
presentation-entities. 

6. Presentation  Laver  -  The  purpose  of  the  presen¬ 
tation  layer  is  to  provide  the  set  of  services 
which  nay  be  selected  by  the  application  layer  to 
enable  it  to  interpret  the  leaning  of  the  data 
exchanged.  These  services  are  for  the  management 
of  the  entry,  exchange,  display  and  control  of 
structured  data.  The  presentation-service  is  loca¬ 
tion  independent  and  is  considered  to  be  on  top  of 
the  session  layer  which  provides  the  service  of 
linking  a  pair  of  presentation-entities.  It  is 
through  the  use  of  services  provided  by  the 
presentation  layer  that  applications  in  an  open 
systems  interconnection  environment  can  communi¬ 
cate  without  unacceptable  costs  in  interface  vari¬ 
ability,  transformations  or  application 
modification.  There  are  four  phases  of  presenta¬ 
tion  layer  protocol  operation: 

a)Session  establishment  phase  in  which 
the  connection  is  set  up. 


fc)  Presentation  image  control  phase  in 
which  the  presentation  options  can  be 
selected  by  value,  by  name,  by  prior 
agree nent  or  by  negotiation. 

c)  Data  transfer  phase  which  controls  the 
data  structure  accesses  and  perhaps 
executes  special  purpose  transfcrma- 
tions  such  as  voice  conpression  or 
data  encryption. 

d)  Termination  phase 

7.Applicat  iqn  Lav  er  -  This  is  the  highest  layer  in 
the  reference  so  del  of  open  systems  interconnec¬ 
tion  architecture.  Protocols  of  this  layer 
directly  serve  the  end  user  by  providing  the 
distributed  information  service  appropriate  to  an 
application,  to  its  management  and  to  the  system 
management.  Hanagement  of  open  systems  intercon¬ 
nection  comprises  those  functions  required  to 
initiate,  maintain,  terminate  and  record  data 
concerning  the  establishment  of  connections  for 
data  transfer  amcng  application  processes.  The 
ether  layers  exist  only  to  support  this  layer. 
Three  categories  of  application  layer  protocols 
are  defined: 

a)  System  Hanagement  Protocols  -  respon¬ 
sible  for  controlling  and  supervising 
open  systems  (e.g. ,  initiating 
dialog) . 

b)  Application  Hanagement  Protocols  - 
responsible  for  controlling  and  super¬ 
vising  application  processes  (e.g., 
access  control)  . 
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III.  BTBBBHBT  LOCAL  AH££  BETBOBK 


A.  OVEBfIEB 

Ethernet  is  one  type  of  local  communication  network 
which  makes  use  of  coaxial  cable  as  a  mean  to  transfer  data. 


Figure  3.1  Contention,  Transmission,  and  Idle  States. 

All  stations  in  the  Ethernet  network  aonitor  the  cable  (the 
ether)  daring  their  cwn  transmission,  terminating  transmis¬ 
sion  immediately  if  a  collision  is  detected. 

The  Ethernet  mechanism  is  modeled  in  Fig.  3.1.  At  the 
point  marked  tp  a  station  has  finished  transmitting  its 
packet.  Any  other  stations  having  a  packet  to  send  nay  now 
attempt  to  do  so.  If  two  or  more  stations  decide  to  transmit 
simultaneously,  there  will  be  a  collision.  Bach  will  detect 
the  collision,  abort  its  transmission,  wait  a  random  period 
of  time,  and  then  try  again,  assuming  that  no  other  station 
has  started  transmitting  in  the  mean  time.  Ethernet  will 
therefore  consist  of  alternating  contention  and  transmission 
periods,  with  idle  periods  occurring  when  all  stations  are 
guiet. 
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B.  CCICISE  ETBBBHST  SPECIFICATIOB 
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figure  3.2  Ethernet  Packet  Foreat. 


A  station  vast  be  able  to  transait  and  receive  packets  on 
the  eceacn  coaxial  cable  with  the  indicated  packet  fcrmat 
and  spacing.  Each  packet  should  be  viewed  as  a  sequence  of 
8- bit  bytes;  the  least  significant  bit  of  each  byte 
(starting  with  the  preamble)  is  transaitted  first. 

a)  . Baxiaua  Paptet  Size:  1526  bytes(8  byte  preaable  14 

byte  header  ♦  1500  data  bytes  ♦  4  byte  CRC) 

b)  . Hiniaua  Packet  $ize;  72  bytes  (8  byte  preaable  ♦  14 

byte  header  ♦  46  data  bytes  ♦  4  byte  CSC) 

c)  . Preaable:  Thi3  64-bit  synchronization  pattern  contains 

alternating  I's  and  0's,  ending  with  two  consecutive 

1«s. 

d)  . Destination  Address :  The  48-bit  field  specifies  the 

station  (s)  to  which  the  packet  is  being  transaitted. 

Each  station  exaaines  this  field  to  determine  whether 

it  should  accept  the  packet.  The  first  bit  transmitted 
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indicates  the  type  of  address.  If  it  is  a  0,  the  field 
contains  the  unique  address  of  the  one  destination 
station.  If  it  is  a  1 ,  the  field  specifies  a  logical 
grcup  cf  recipients;  a  special  case  is  the,  broadcast 
(all  stations)  address,  which  has  all  1's. 

e)  . Source  Address:  This  48-bit  field  contains  the  unique 

address  of  the  station  that  is  transacting  the  packet. 

f)  -Il-Ef  ?ield:  This  16-bit  field  is  used  to  identify  the 

higher  level  protocol  type  associated  with  the  packet. 
It  deteraines  hew  data  field  is  interpreted. 

g)  • D§t3  Field:  The  field  contains  an  integral  nuaber  of 

bytes  ranging  froa  46  to  1500.  (The  miniaua  ensures 
that  valid  packets  will  be  distinguishable  froa  colli¬ 
sion  fzagaents.) 

h)  . Packet  Check  Sequence :  This  3 2- bit  field  contains  a 

redundancy  check  (CSC)  code,  defined  by  the  generating 
pclynoaial: 

6  (X)  *  |M  +  x2*  +  X*3  +  x22+Xl‘*ll*+X11 
♦  X‘®+X»  +  X  »+X*+X*  +  X*  +X  +  1 

The  CBC  covers  the  address  (destination/source)  ,  type, 
and  data  fields.  Ibe  first  transacted  bit  of  the  desti¬ 
nation  field  is  the  high-order  term  of  the  message 
pclyncaial  to  be  divided  by  G(x)  producing  reaainder 
8  (x)  .  The  high-order  term  of  8  (x)  is  the  first  trans¬ 
acted  bit  of  the  Packet  check  Sequence  field.  The  algo- 
ritha  uses  a  linear  feedback  register  which  is  initially 
preset  to  all  1's.  After  the  last  data  bit  is  trans¬ 
acted,  the  contents  cf  this  register  (the  reaainder) 
are  inverted  and  transacted  as  the  CBC  field.  After 
receiving  a  good  packet,  the  receiver's  shift  register 
contains  1  10001  11  00000100  1101  1101  01  111011  (x^... 


i)  -iiaiias  Packet  Spacing:  This  spacing  is  9.6  microse¬ 

cond  ,  The  ainiau*  tiae  that  aust  elapsa  after  one  tran- 
saissicn  before  another  transmission  nay  begin. 

j)  . poupd-Tp3-p  pejay:  The  maximum  end-to-end,  round-trip 

delay  for  a  bit  is  51.2  aicrosecond. 

k)  -SSlli^icn  Filtering:  Any  received  bit  sequence  saaller 

than  the  ainiaua  valid  packet  (with  minimum  data  field) 
is  discarded  as  a  collision  fragment. 

2 .  t£2i  £I££S jjffl 

The  control  procedure  defines  hov  and  when  a  hcst 
station  aay  trasait  packets  into  the  common  cable.  The  key 
purpose  is  a  fair  resolution  of  occasional  contention  among 
transmitting  stations. 

a)  .Defer:  A  station  aust  not  transmit  into  the  coax  cable 

when  the  carrier  is  present  or  within  the  minimum 
packet  spacing  tiae  after  the  carrier  has  ended. 

b)  . Transmit:  A  station  may  transmit  if  it  is  not  defer¬ 

ring.  It  aay  continue  to  transmit  until  either  the  end 
of  the  packet  is  reached  or  a  collision  is  detected. 

c)  . Abort:  If  a  collision  is  detected,  transmission  of  the 

packet  must  terainat9,  and  a  1am  (4-6  bytes  of  arbi¬ 
trary  data)  is  transmitted  to  ensure  that  all  ether 
participants  in  the  collision  also  recognize  its  occur¬ 
rence. 


d) . Betransnd  t :  After  a  station  has  detected  a  collision 
and  aborted,  it  must  wait  for  a  random  retransmission 
flelav,  defer  as  usual,  and  then  attempt  to  retransmit 
the  packet.  The  randoa  tiae  interval  is  computed  using 
the  backoff  algorithm  (below).  After  16  retransmission 
attempts,  a  higher  level  (e.g.  software)  decision  is 
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made  tc  determine  whether  to  continue  or  abandon  the 
effort. 

e)  .B§£kofij:  Betransaission  delays  are  coaputed  using  the 
Truncated  Exponential  Backoff  algorithm,  with 

the  aia  of  fairly  resolving  contention  among  up  to  1024 
stations.  The  delay  (the  nuaber  of  tine  units)  before 
the  n1h  attempt  is  a  uniformly  distributed  random  number 
from  0  to  2  for  0<n<10  (n  *  0  is  the  original  attempt)  . 
For  attempt  11-15,  the  interval  is  truncated  and 
remains  at  0  to  1023.  The  unit  of  time  for  the  retrans¬ 
mission  delay  is  512  bit  times  (51.2  microsecond). 

3 •  Channel  Encoding 

Hanchester  encoding  is  used  on  the  coaxial  cable.  It 
has  a  50*  duty  cycle,  and  insures  a  transition  in  the  middle 
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Figure  3.3  Data  Bate  Scheae. 

cf  every  bit  cell  ("data  transition").  The  first  half  of 
the  bit  cell  contains  the  complement  of  the  bit  value,  and 
the  second  half  contains  the  true  value  of  the  bit. 
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4 .  fata  gate 

Data  rate  is  10  Mbit/sec  3  100  nsec  bit  cell  ± 

0.011. 

5  •  Carrier 

The  presence  of  data  transitions  indicates  that 
carrier  is  present.  If  a  transition  is  not  seen  between 
0.75  and  1.25  bit  tines  since  the  center  of  the  last  bit 
cell,  then  carrier  has  been  lost,  indicating  the  end  of  a 
packet.  For  purposes  of  deferring,  carrier  means  any 
activity  cn  the  cable,  independent  of  being  properly  formed. 
Specifically,  it  is  any  activity  on  either  receive  or  colli¬ 
sion  detect  signals  in  the  last  160  nsec. 

6.  Coax  Cable 

a)  .Impedance:  50  chms  ±  2  ohms  (Mil  Std.  C17-E).  This 

impedance  variation  includes  batch-to-batch  variations. 
Eeriodic  variations  in  impedance  of  upto  ±  3  ohms  are 

permitted  along  a  single  piece  of  cable. 

b)  » Cable  Loss :  The  maximum  loss  from  one  and  of  a  cable 

segment  to  the  ether  end  is  8.5  db  at  10  MHz  (equiva¬ 
lent  tc  °500  meters  of  low  loss  cable). 

c)  . Shielding :  The  physical  channel  hardware  must  operate 

in  ar  ambient  field  of  2  volts  per  meter  from  10  MHz  to 
30  MHz  and  5  volts  per  meter  from  30  MHz  to  1  GHz.  The 
shield  has  a  transfer  impedance  of  less  than  1  milliohm 
per  meter  over  the  fraguency  range  of  0.1  MHz  to  20  MHz 
(exact  value  is  a  function  of  frequency)  . 

d)  .Ground  Connection:  The  coax  cable  shield  shall  net  be 

connected  to  any  building  or  AC  ground  along  its 
length.  If  for  safety  reasons  a  ground  connection  of 
the  shield  is  necessary,  it  must  be  in  only  one  place. 
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a)  » ffrvsjgal  Dimensions:  This  specifies  the  dimension  of  a 
cable  which  can  be  used  in  the  standard  tap,  ether 
cables  nay  alsc  be  used,  if  they  are  not  to  be  used 
with  a  tap-type  transceiver  (such  as  used  with  connec- 
torized  transceivers,  or  as  a  section  between  sections 
to  which  standard  taps  are  connected)  . 

Center  Conductor:  0.0855"  diameter  solid  tinned  copper 

Core  Haterial:  Foam  polyethylene  or  foam  teflcn  FEP 

Core  O.D.:  0.242"  minimum 

Shield:  0.  326"  maxiaua  shield  O.D. 

Jacket:  PVC  or  teflon  FEP 

Jacket  O.E.  :  0.405" 


Figure  3.4  Coax  Cable,  connectors,  and  Transceivers. 


7 .  Cs§x  connectors  and  Teninators 

Coax  cables  must  be  terainated  with  male  N-series 
connectors,  and  cable  sections  will  be  joined  with  fesale- 
feaale  adapters.  Connector  shells  shall  be  insulated  such 
that  the  coax  shield  is  protected  froa  contact  to  building 


grounds,  k  sleeve  cr  boot  is  acceptable.  Cable  segments 
should  be  terminated  with  a  female  N-series  connector  (can 
be  made  up  of  a  barrel  connector  and  a  male  terminator) 
having  an  impedance  cf  50  ohms  ♦  1%,  and  able  to  dissipate  1 
watt.  The  outside  surface  of  the  terminator  should  also  be 
insulated. 

8 .  Transceiver 

Op  tc  100  transceivers  may  be  placed  cn  a  cable 
segment  nc  closer  than  2.5  meters.  Following  this  placement 
rule  reduces  to  a  very  low  (but  not  zero)  probability  the 
chance  that  objectionable  standing  waves  will  result.  The 
details  of  transceiver  interface  and  coax  cable  interface 
can  be  fcund  in  Interlan's  "Concise  Ethernet  Specification" 
[Ref.  3]. 

C.  111010  OHI BOS  ETHERNET  COHHOHICATIOHS  CONTROLLER 

1 .  lotoses 

a)  . Ethernet  Dqta  Link  Layqr  Functions: 

1)  .Data  Sncapsulati on/decapsulation 

2)  .Carrier  Sense  Hultiple  Iccess/Collision  Detected 

(CSHA/CD)  transmit  and  receive  data  link  management 

b)  . Ethernet  ph vsical  Channel  Functions: 

1)  .  10  Kbits  per  second  data  rate 

2)  .Data  encoding  and  decoding 

3) . Channel  access 

4)  .Transceiver  cable  interface 

c)  .  jiftwoyk  5 tatist  ics: 

1). Tallies  number  of  transmissions.  ~eceptions,  errors, 
and  collisions 

*) • £ s 
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1)  .  16  Kbytes  FIFC  buffer  for  back-to-back  frame  recep¬ 

tion 

2) .  2  Kbyte  FIFO  buffer  for  frame  transmission 

3)  .EH A  transfers  to/from  unibus  memory 

e)  . Extensive  Diagnostic  Features: 

1) . internal  and  external  data  loop-back  operation 

2)  .Network  LED  indicators 

3) .Ecwer-up  confidence  test 

4) . Pass/fail  LED  indicator 

5)  .Diagnostic  software  provided 

f)  . $ne  be x -flight  Beard: 

1)  .Fit  one  unibes  SPC  slot 

2  •  £escii£ti^n 

The  Nil 010  Onibus  Ethernet  Communication  Controller 
Board  is  a  single  Hex-height  board  that  contains  all  the 
data  communications  controller  logic  required  for  inter¬ 
facing  DEC'S  family  of  VAX- 11  and  Onibus-based  PDP-11  mini¬ 
computers  to  the  Ethernet  local  area  network.  It  performs 
the  specified  data  link  and  physical  channel  functions, 
permitting  Onibus-based  systems  to  engage  in  transmission 
and  reception  of  data  with  other  Ethernet  stations  on  the 
local  area  network  with  the  speed  of  10  Mbit  per  second  and 
with  the  maximum  distance  of  2500  meters.  As  shown  in  Figure 
3.5,  the  Nil 010,  when  attached  to  a  transceiver  unit, 
provides  a  VAX-11  or  Onibus-based  PDP-11  a  complete  connec¬ 
tion  onto  the  Ethernet  local  area  network. 

3*  Ethernet  link  layer  functions 

Hithin  the  data  link  layer  the  NI1010  performs  the 
specified  Ethernet  transmitter  processes  of  Transmit  Data 
Encapsulation  and  Transmit  Link  Management,  and  the  Ethernet 
receive  processes  of  Deceive  Data  Decapsulation  and  aeceive 
Link  Management. 


38 


The  Destination  Address  field  specifies  the 
station  (s)  for  which  the  frame  is  intended.  The  address 
value  provided  by  the  user  nay  be  either:  1)the  physical 

address  of  a  particular  station  on  the  network;  2)  a 
■ulticast-grcup  address  associated  with  one  or  more 
stations;  or  3) the  broadcast  address  for  simultaneous  tran- 


Figure  3.6  Ethernet  Frame  Format* 


saissicn  to  all  stations  on  the  network.  The  first  bit  of 
the  Destination  Address  distinguishes  a  physical  address 
from  a  multicast  address  (0  *  physical,  1  *  multicast)  .  For 
broadcast  transmissions  an  all  one-bit  pattern  is  used. 

The  Source  Address  field  specifies  the  physical 
address  cf  the  transmitting  station.  To  eliminate  the  possi¬ 
bility  of  an  addressing  ambiguity  on  a  network,  associated 
with  each  NI1Q10  is  a  unique  48-bit  physical  address  value 
assigned  to  it  at  the  time  cf  manufacture.  On  transmission, 
the  ST^OIO  inserts  this  value  into  the  Source  Address  field. 

The  type  field  is  specified  by  the  user  for  use 
by  high  level  network  protocols.  It  specifies  to  the 
receiving  station(s)  how  the  content  of  the  Data  field  is  to 
be  interpreted. 


The  Data  field  say  contain  a  variable  number  of 
data  bytes  ranging  from  a  minimum  of  46  bytes  to  a  maximum 
of  1500  bytes.  The  NI1010  accepts  less  than  46  bytes  from 
the  user  by  automatically  inserting  null  characters  to 
complete  a  46-byte  minimum  frame  size. 

The  Frame  Check  Sequence  (PCS)  field  contains  a 
32-bit  cyclic  redundancy  check  (CSC)  value  generated  by  the 
Mil 0 1 0  during  transmission. 

b.  Transmit  link  management 

The  Nil 010  performs  all  Ethernet  Transmit  Link 
Management  functions  required  to  successfully  deliver  a 
frame  ontc  the  network.  These  functions  include: 

•  Carrier  Deference;  the  Nil 010  monitors  the  physical 
channel  and  defers  its  transmission  should  the  channel 
be  busy  carrying  ether  traffic; 

•  Collision  Detection;  once  the  Nil 010  has  finished  defer¬ 
ring  to  the  passing  traffic  on  the  network,  it  proceeds 
with  its  own  transmission.  In  the  event  that  another 
station  simultaneously  began  a  transmission,  a  "cclli- 
sicn"  occurs.  The  NI1Q10  detects  this  event  and  termi¬ 
nates  its  transmission  attempt;  and 

•  collision  Backoff  and  Retransmission;  when  a  transmis¬ 
sion  attempt  has  been  terminated  due  to  a  collision  the 
NI1010  attempts  its  transmission  again  after  delaying  a 
short  random  period  of  time.  The  scheduling  of  the 
retransmission  is  determined  by  the  Ethernet  process 
called  "truncated  binary  exponential  backoff".  The 
NI1010  reports  an  error  should  it  be  unable  to  deliver 
its  frame  onto  the  network  after  16  transmission 
attempts. 
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c.  Beceive  data  decapsulation 

When  not  transmitting  a  frame  the  NI1010  conti¬ 
nuously  listens  to  the  traffic  being  carried  on  the  network. 
After  synchronizing  to  the  preamble  sequence  of  a  frame  on 
the  network,  the  NI1010  processes  the  Destination  Address 
field  through  its  address  filter  logic  to  determine  whether 
or  net  the  incoming  frame  is  intended  for  it.  The  Nil 010 
controller  will  only  accept  a  frame  from  the  network  with  a 
Destination  Address  value  that  either: 

1)  matches  the  physical  address  of  the  NI1010  board 
itself; 

2)  contains  the  broadcast  address;  or 

3)  matches  one  of  the  63  multicast -group  logical 
addresses  which  the  user  may  assign  to  the  board. 

The  NI1010  performs  high  speed  multicast-group 
address  recognition.  Whenever  a  multicast-group  logical 
address  is  received  cn  the  network,  the  NI1010  converts  the 
frame's  48-bit  Destination  Address  field  into  a  6-bit  table 
entry  pointer  through  the  application  of  a  many-tc-few 
mapping  called  "hashing”.  It  uses  the  resulting  pointer  to 
look  into  a  table  of  valid  multicast-group  addresses  to  see 
if  the  received  address  is  one  that  the  station  should 
accept. 

For  network  management  and  diagnosis,  the  Nil 010 
may  be  operated  in  a  "promiscuous"  receive  mode.  When  in 
this  mode,  the  NI1010  disables  its  address  filter  lcgic  and 
accepts  all  undamaged  frames  passing  on  the  network. 

The  NI10  10  validates  the  integrity  of  a  received 
frame  by  regenerating  the  32-bit  CSC  value  on  the  received 
bit  stream  and  comparing  it  against  the  CBC  value  found  in 
the  frame's  Frame  Check  Sequence  field. 
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3.  Receive  lick  management 


Since  collisions  are  a  normal  occurrence  in  the 
Ethernets  CS  M  A/CD  link  management  process,  the  NI1G10 
receiver  filters  out  collision  fragments  from  valid  frames. 

4.  Ethernet  physical  layer  functions 

Sithin  the  Ethernet  Physical  Layer  the  NI1010 
performs  the  electrical  and  procedural  specifications 
required  fcr  interfacing  directly  to  a  transceiver  unit. 
Transmissions  and  receptions  take  place  at  a  10  Mbits  per 
second  data  rate  under  half-duplex  operation. 

a.  During  transmission  the  NIIOIO's  physical 
channel  functions  include: 

1)  .Generating  the  64-bit  preamble  sequence  for  all 

receivers  on  the  network  to  synchronize  on; 

2)  .Earallel  to  serial  conversion  of  the  frame; 

3)  .Calculating  a  32-bit  CBC  value  and  inserting  it  into 

the  Frame  Check  Sequence  field; 

4)  .Generating  a  self-sy nchronizing  serial  bit  stream 

thrcugh  Manchester  encoding  of  the  data;  and 

5)  .Providing  proper  channel  access  by  detecting  carrier 

frcm  another  station's  frame  transmission,  and  sensing 
the  collision  presence  signal  from  the  transceiver 
unit. 


b.  The  NIIOIO's  physical  channel  functions  during 
reception  include: 

1)  .  Manchester  decoding  the  incoming  bit  stream  into  a  data 
stream  and  a  deck  stream; 
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2)  .Synchronizing  to,  and  removal  of,  the  preamble 

sequence;  and 

3) .  Serial  to  Parallel  conversion  of  the  fraae. 


5 .  Performance 

The  NI1010  has  been  designed  to  offer  high  network 
perforaance  while  ainiaizing  the  service  loads  placed  upon 
the  host  Onibus  systea. 

Serving  to  buffer  the  system  froa  the  unpredictable 
interarrival  tiaes  characteristic  of  network  traffic,  the 
board  has  a  PIFO  {first-in,  first-out)  memory  which  can 
store  up  to  16  Kbytes  of  received  frames.  Because  of  this 
extensive  front-end  buffering,  few  tiae-cr itical  service 
requirements  are  iapcsed  on  the  host  Onibus  systea. 

Fcr  transmission,  the  NI1010  has  a  2  Kbyte  Transait 
FIFO  which  permits  the  host  to  perfora  a  one-time  transfer 
of  a  fraae. 

ill  data  block  transfers  between  the  Nil 010  and 
Onibus  memory  are  performed  under  the  control  of  an  onboard 
DMA  controller.  To  maximize  systea  performance  during  recep¬ 
tion,  the  controller  allows  the  user  to  preload  up  to 
sixteen  different  memory  buffer  address  and  byte  count 
values  fcr  EMi  of  received  frames. 

6.  Ijtessiis  filagpgstjc  Features 

The  NI1010  offers  coaprehensive  network  and  beard- 
level  diagnostic  tools  which  greatly  simplify  the  process  of 
identifying  a  network  comaunication  problem.  Mounted  on  the 
edge  of  the  board  are  four  network  state  LED  indicators 
which  provide  a  visual  indication  of  whether  or  not  the 
user's  station  is  ccmaunicating  onto  the  network.  For  a 
coaprehensive  station  diagnosis,  the  user  can  exercise  the 
H1 1 0 1 0 ' s  ccaai unication  facilities  in  either  internal  or 
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Figure  3.7  1X1010  Functional  Diagraa. 

external  data  loopback  mode;  aaking  it  possible  to  detect 
and  isolate  a  fault  to  the  coaxial  cable,  transceiver  unit, 
transceiver  cable;  or  the  NI1010  board  itself. 

Cn  power-up  the  Nil  010  perforas  a  confidence  test  of 
the  cnbcard  aeaories,  register  and  data  paths.  &  LED  indi¬ 
cator  shoes  the  pass/fail  operational  state  of  the  board. 

7 •  statistics 

The  N1 10 10  collects  network  statistics  to  permit  the 
user  to  ckaracterize  network  operation.  Statistics  tallied 
include: 

a)  .number  of  fraaes  received 

b)  .nuaber  of  fraaes  received  with  CRC  error 

c) .cuaber  cf  fraaes  received  with  alignment  error 
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d)  .Quaker  of  fraaes  transaitted 
a). Quaker  of  transiit  collisions 


Per  detailed  description  of  NI1010  Ethernet 
Coaaunicaticn  Controller  Board,  see  HI1010A  Onibus  Ethernet 
Coaaunicaticns  Ccntrcller  User  Manual  [Hef.  4  1. 


If.  D8T  HI  ED  DESIGH  AMD  I HPLEHEHTATIOH 


A.  DESIGN  ISSUES  COBSXDERATIOI 

After  studying  tbe  NI1010  Onibus  Ethernet  Communications 
Controller  in  detail,  some  of  the  common  problems  with  the 
design  of  protocol  mentioned  in  Chapter  II  can  be  solved  as 
follows: 

1. The  method  needed  for  a  process  on  one  machine  to 
specify  who  it  wants  to  talk  to  is  the  Destination 
Address  and  the  Source  Address  field  in  every  trans¬ 
mitted  frame. 

2.  There  is  no  need  to  find  a  mechanism  for  terminating  the 
connection  across  the  network,  since  the  Ethernet  will 
put  itself  to  the  idle  state  automatically  if  there  is 
no  carrier  on  the  coax  cable. 

3.  The  rule  for  data  transfer  is  fixed  on  the  half-duplex 
operation, i.e. ,  the  data  can  travel  in  either  direction, 
but  not  simultaneously. 

4.  For  the  error  control  issue,  Ethernet  frame  format 
provides  a  32-bit  Frame  Check  Sequence  field  which 
contains  Cyclic  Fedundancy  Check  (CHC)  value.  This 
value  is  generated  by  the  Ethernet  board  of  the  sending 
station  and  will  be  checked  by  the  board  of  the 
receiving  station. 

5.  The  problem  of  how  to  keep  a  fast  sender  from  swamping  a 
slow  receiver  with  data  is  solved  by  the  16  Kbyte  FIFO 
Receive  buffer  on  all  Ethernet  boards. 
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6. Ethernet  board  performs  data  link  layer  in  transmitting 
data  encapsulation  and  receive  data  decapsulation.  The 
data  field  of  the  frame  format  can  vary  from  46  to  1500 
bytes.  Thus,  the  design  issue  of  the  ability  of 
processing  arbitrarily  long  messages  is  solved. 
Furthermore,  if  the  data  is  less  than  46  bytes,  the 
board  will  automatically  insert  null  characters  to 
complete  a  46-byte  minimum  frame  size. 

However,  the  problem  of  preserving  the  order  of  messages 
is  net  solved  by  the  capability  of  the  Ethernet  board.  The 
design  of  a  higher  layer  protocol  would  have  to  take  this 
issue  into  consideration.  The  forthcoming  sections  will 
explain  hew  to  create  a  design  such  that  it  will  overcome 
this  problem. 

The  H1 1010  Onibus  Ethernet  communications  Controller 
Board  together  with  the  Transceiver  represent  the  first  two 
layers,  Physical  Layer  and  Data  Link  Layer,  of  the  ISO 
fieference  Model  as  shown  in  Figure  4.1. 

B.  1S2030  DEVICE  DRIVER 
1 .  Overview 

The  HS2030  product  includes  a  diagnostic  program  and 
a  VAX/VMS  device  driver  source,  hereafter  referred  to  as 
NIDRIVER,  that  allows  a  suitably  privileged  application 
program  written  in  VAX- 11  MACRO  assembly  language  or  any 
VAX/VMS  high  level  language  (such  as  VAX-11  FORTRAN)  to 
interface  tc  INTERLAN*s  Onibus  tc  Ethernet  interface,  the 
H1 10 1 0.  The  application  program  uses  standard  Vjx/VHS 
services  to  interface  to  the  Ethernet.  There  are  nc  new 
interfaces  tc  learn.  NIDRIVER  supports  all  features  of  the 
H1 1 0 1 0  controller,  including  full  duplex  operation  (trans¬ 
mitting  with  receives  outstanding)  ,  non-contiguous  buffers 
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Figure  4.1  111 010  and  ISO  Reference  Model. 

for  transeission  and  reception  (often  called  "scatter/ 
gather"  cr  "buffer  chaining")  ,  and  the  extensive  ontoard 
intelligence  and  diagnostic  functions.  The  standard  QIO 
interface  allows  the  network  software  designer  to  choose 
among  several  techniques  for  perforaing  I/O:  synchronous 

1/0  using  the  SQIOW  systea  service ,  and  asynchronous  I/O 
using  the  SQIO  system  service  with  event  flags  and/or  AST 
routines. 
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Hith  one  $QIC  request,  an  application  program  is 
able  tc  instruct  the  NI1010  to  obtain  a  preformatted 
Ethernet  packet  out  cf  system  memory  and  transmit  it  onto 
the  Ethernet.  Similarly,  with  ope  $QIO  request,  the  pregram 
can  specify  the  address  and  length  of  a  buffer  in  system 
memory  into  which  the  controller  can  place  the  next  received 
packet.  Single  SQIO  requests  can  also  be  used  to  perform 
ether  NI1010  functions  such  as  GO  ON-LINE,  RON  DIAGNOSTICS, 
REPORT  STATISTICS,  and  LOAD  GROOP  ADDRESS  (ES)  . 

The  detailed  description  of  NIDRIVER  is  contained  in 
the  Interlan  NS2030  VAX/VMS  (TS)  Device  Driver  and 
Diagnostics  Oser  Manual  [Ref.  5]. 

2.  Program  interfaces  to  NIDRIVER 

Detailed  descriptions  of  the  following  standard 
VAX/VHS  system  services  can  be  found  in  the  VAX/VMS  System 
Services  Reference  Manual  [Ref.  6]  and  in  the  VAX/VMS  I/O 
User's  Guide  [Ref.  7].  Some  of  the  very  important  system 
services  are  also  included  in  Appendix  A. 

a.  Using  Sassign  (associate  channel)  with  NIDRIVER 

Before  a  program  can  issue  requests  to  NIDRIVER, 
it  must  assign  a  channel  to  the  NI1010  controller.  The 
Assign  I/O  Channel  (SASSIGN)  system  service  is  used  to 
assign  a  channel  to  a  device.  You  supply  the  device  name  as 
part  cf  the  SASSIGN  call:  SASSIGN  returns  a  channel  number. 
The  Nil 3 10  controller  device  name  supported  by  NIDBIVER  is 
cf  the  form  mxy:  Because  the  NI1010  controller  represents  a 
single  "unit"  (in  the  VMS  I/O  sense) ,  the  first  controller 
is  called  "NIA0:w,  the  second  "NIBO:",  and  so  on. 
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fc.  Using  SAIIOC  (allocate  device)  with  NIDRIV2B 

A  process  can  allocate  a  device  for  its  exclu¬ 
sive  use  using  the  SAILOC  system  service.  Once  the  device  is 
allocated,  no  other  process  (except  for  subprocesses  related 
to  the  issuing  process)  can  assign  a  channel  to  the  device. 

Because  the  Nil  010  controllers  provide  low  level 
access  to  the  Ethernet.  NIDBIVEB  supports  each  controller  as 
a  aon-sharable  device.  When  a  process  assigns  a  channel  to 
an  NI1010  controller,  VAX/VNS  performs  an  implicit  SALLOC 
for  the  process. 

c.  Using  SGETCHN  and  JGETDEV  (get  device 

Informa  ticn) 

Two  system  services  can  be  used  to  obtain  infor¬ 
mation  abcut  NIDBIVEB:  Get  Channel  Information  (SGETCHN)  and 
Get  Device  Information  (SGETDEV)  .  SGETCHN  is  used  to  obtain 
information  about  a  specific  device. 

When  used  to  obtain  information  about  an  Nil  010 
controller,  these  system  services  return  identical  primary 
and  secondary  device  characteristics. 

d.  Using  SQIO  and  SQIOW  (request  I/O  function) 

Because  NIDBIVEB  supports  the  standard  VAX/VHS 
QIO  interface,  all  controller  requests  follow  the  general 
CIO  format: 

$QIC_S  [  efn  ],chan,func,[  iosb  ],[astadr  ],[  astprm  ], 
[ptMp2MF3],£p4],[p5],[p6] 

The  first  six  arguments  are  device/function 
independent  and  can  be  used  in  any  controller  I/O  request. 
For  example,  you  can  specify  an  AST  routine  address  (the 
"astadr”  argument  of  the  QIO  request)  if  you  need  to  execute 
special  cede  at  I/O  completion. 


Device/f unction  dapendent  arguments  PI  and  P2 
must  be  supplied  for  all  controller  operation  that  use  the 
DBA  channel  for  transferring  data  to  or  from  VAX  memory.  PI 
is  the  (virtual)  address  of  a  ROHD-ALIGHED  buffer.  P2  is  the 
size  of  the  buffer  in  bytes  and  must  be  even  and  less  than 
1536  (decimal).  Parameter  P3  through  P6  are  ignored  in 

NX1010  operations. 

(1)  .  funct  ions.  To  fully  understand  the 

I/O  functions  supported  by  NIDRIVER,  one  should  knee  how 
VAX/ V HS  I/O  functions  are  encoded  into  16-bit  values  (the 
function  argument  of  the  QIO  request)  .  I/O  function  values 
have  the  following  fermat: 

15  6  5  0 

♦- - — — - - - - + - ♦ 

function  modifiers  code 

♦  - - - - + - *■ 

The  low-order  6  bits  of  the  function  value 
are  a  code  that  specifies  the  particular  operation  to  be 
performsd.  The  high-erder  10  bits  of  the  function  value  are 
function  modifiers  and  are  normally  used  to  alter  the  parti¬ 
cular  operation  specified  by  the  code.  Symbolic  names  for 
function  codes  and  modifiers  are  defined  by  the  SIODEF 
macro,  as  described  in  the  VAX/VHS  System  Services  Reference 
Manual  [Hef.  6].  A  modified  function  can  be  invoked  by 
ltORMing  a  function  code  and  function  modifier.  For  example: 

IO$_SETMODE!IO$_SHUTDOWN 
in  MACRO  assembly  language,  or 

IO$_SETMODE  .OR.  IO$_SHOTDORH 

in  FOBIRAH. 
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The  following  describes  each  I/O  function 
suppcrted  b;  NIDRIVER. 

10$  SETMODEI  10$  STARTUP 

Issuing  a  QIO  with  a  Mfunc"  argument  of 
I0$_ SET MODE !  I0$_ST  ARTUP  causes  NIDRIVER  to  begin  controller 
operation.  NIDRIVER  will  allocate  necessary  VAX/VMS 
resources  and  pass  a  GO  ON-LINE  command  to  the  NI1Q10  cont¬ 
roller.  The  controller  and  driver  will  now  be  in  a  state  to 
process  commands  and  receive  packets. 

Cne  can  modify  NIDRIVER's  resource  allocation  strategy  at 
run-time.  To  change  strategy,  one’s  program  must  supply  (in 
the  IC$— SET  MODE!  IO$_STARTUP  QIO)  the  address  of  a  quadword 
characteristics  buffer  in  parameter  PI  and  the  size  in  bytes 
(always  16)  of  the  characteristics  buffer  in  P2.  The  first 
longwcrd  (32-bit  word)  of  the  characteristics  buffer  is 
interpreted  by  NIDRIVER  as  follows: 

<3:0>  the  maximum  number  of  receive  buffers  that 
NIDRIVER  will  pass  to  the  controller  with  supply 
RECEIVE  BUFFER  commands  (maximum  of  16)  .  NIDRIVER 
will  allocate  5  Unibus  Adapter  map  registers  for 
each  as  a  result  of  this  call.  If  this  field  is 
zero,  NIDRIVER  will  use  a  default  value  of  4  and 
allocate  20  map  registers  for  receive  operations. 
(Five  additional  map  registers  are  ALWAYS  allo¬ 
cated  for  command  DMA.) 

<31:4>  RESERVED  (must  be  zero) 

The  second  longwcrd  of  the  characteristics  buffer  is  inter¬ 
preted  by  NIDRIVER  as  follows: 

<,':C>  *  0  (Default)  Allocate  a  Buffered  Data  Path 

only  when  needed  to  process  command  operations 


that  perform  DMA.  Deallocate  the  Buffered  Data 
Path  iooediately  after  the  command  is  finished. 

<0:0  *  1  Permanently  allocate  a  Buffered  Data  Path 

tc  be  used  for  command  operations  that  perform 

DMA. 

<3 1 ;  1  >  RESERVED  (must  be  zero) 

10$  SETMODE ! 10$  SHUTDOWN 

Issuing  IO$_SETMODE !  IO$_SH  UTDOWN  causes  NIDRIVER  to  shut 
down  network  operations.  NIDRIVER  passes  a  RESET  command  to 
the  controller.  All  outstanding  receive  (IO$_READLBLK) 
requests  will  finish  with  a  status  of  SS$_ABORT.  Any  allo¬ 
cated  Buffered  Data  Path  will  be  deallocated.  Any  supplied 
characteristics  buffer  is  ignored  for  this  call. 

10$  HBITELBLK 

Issuing  IO$_WBITELBIK  causes  the  packet  defined  by  QIO 
parameters  PI  and  P2  to  be  transmitted  onto  the  Ethernet.  PI 
is  the  address  of  a  WORD  ALIGNED  preformatted  packet  in 
memory.  P2  is  the  length  in  bytes  of  the  preformatted 
packet.  P2  must  be  greater  than  0  and  less  than  1536 
(decimal)  and  even.  The  packet  must  follow  the  format 
described  in  Pigure  4.2.  The  QIO  request  will  remain 
outstanding  until  the  packet  is  successfully  transmitted 
onto  the  Ethernet  (or  an  error  occurs)  .  The  I0$_WRITEPBLK 
function  performs  the  same  operation  as  the  I0$_HRITELELK 
function. 

10$  READLELK 

Issuing  IC$_RE  ADLBLK  causes  the  buffer  defined  by  QIO  param¬ 
eters  PI  and  P2  (address  and  size  in  bytes,  respectively)  to 
he  used  to  hold  the  next  received  packet  (or  packet  fragment 
if  buffer-chaining  takes  place).  The  buffer  pointed  to  by  PI 
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Figure  4.2  Transait  Packet  Foraat. 

aust  be  WORD  ALIGNED .  The  buffer  size  passed  in  P2  must  be 
greater  than  0,  less  than  1536  (deciaal)  ,  and  even.  Packet 
placeaent  into  buffers  is  strictly  FIFO;  that  is,  the  oldest 
cutstanding  buffer  will  receive  the  next  incoaing  packet. 
The  foraat  of  the  received  packet  is  shown  in  Figure  4.3. 
The  QIO  reguest  will  reaain  outstanding  until  a  packet  (or 
packet  fragaent)  is  accessed  directly  into  the  associated 
buffer. 
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Figure  4.3  Receive  Packet  Format. 


C  cntroller  Specific  Functions 

Because  no  existing  VAX/VRS  function  codes  correspond  to 
NI1010  specific  operations  such  as  LOAD  HULTICAST  or  SET 
FROHISCOCOS  MODE,  HICBIVEE  supports  driver-specific  function 
codes.  These  codes  are  constructed  by  passing  the 
controller-specific  coaaand  in  the  "function  modifier"  field 
of  the  I/C  function  value.  The  function  value  "code"  field 
will  be  ICI.READLBLK,  IO$_W BITELBLK,  or  IO$_SEEK,  depending 


l'  *  *  «*  •  ’  m*  .  *  »  •  i  •  .  *.*.*  ,  , 
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on  whether  the  cent  teller- specific  command  parforms  direct 
memory  access  or  not.  For  example,  the  following  function 
value  specifies  LOAD  multicast: 

X20  !  <  0  52  9  6>  *  XAAO 

As  a  programming  convenience,  INTEHLAN  provides  symbolic 
names  which  can  be  used  in  the  function  argument  of  QIO 
service  calls.  File  NIDEF.MAR  can  be  used  with  MACRO 
programs  and  file  NID EF.  FOR  can  be  used  with  FORTRAN 
programs. 

One  can  use  these  definitions  in  a  FORTRAN  program  by 
including  the  line: 

INCLUDE  *_DRAO:[NPSSYS.INTERLAN]NIDEF.FOR» 
in  the  FCSTSAN  source  code. 

(2)  •  VO  Completion.  One  should  always  supply 
the  address  of  a  guadword  I/O  status  Block  (IOSB)  IN  THE 
"iosfc"  argument  of  the  QIO  request.  On  I/O  completion,  the 
IOSB  will  contain  not  only  VAX/VMS  status,  but  also  cont- 
roller  specific  status  as  well. 

VAX/VBS  status  is  returned  in  bits  <15:0>  of  the  first  ICSB 
longwcrd.  Bits  <31:16>  of  the  first  IOSB  longword  dc  not 
contain  any  meaningful  information.  If  the  returned  VAX/vns 
status  is  SS$_NORHAL,  Normal  Successful  Completion,  bits 
<3:0>  of  the  second  IOSB  lengword  will  contain  the  Command 
Status  Code  from  the  controller.  Refer  to  the  NI1010  Unibus 
Ethernet  commun icaticns  Controller  User  Manual  [Ref.  4]  for 
a  complete  description  of  the  controller  status  cedes. 
Appendix  F  describes  which  Command  Status  Codes  can  be 
expected  for  each  QIO  request.  Bits  <31:4>  of  the  second 
IOSB  lengwerd  do  not  contain  meaningful  information. 
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C.  DESIGNING  PBOCEDOBE 


Since  NS2030  Device  Driver  is  intended  to  be  used  in 
VAX/VHS  xini-computer*  the  design  is  based  on  Digital 
Equipnent  Corporation's  Network  (DECNET)  rather  than  the  ISO 
Beference  Model  mentioned  in  Chapter  II.  However*  the 
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Figure  4.4  Sapping  between  ISO  flodel  and  DECNET. 


layering  concept  is  still  used  in  DECNET.  The  approximate 
mapping  between  ISO  Beference  Model  and  DECNET  is  shown  in 
Figure.  4.4. 

DECNET  has  only  five  layers.  The  physical  layer*  data 
link  layer,  transport  layer*  and  network  services  layer 
correspond  almost  exactly  to  the  lowest  four  ISO  layers. 
However*  the  agreement  breaks  down  at  layer  5,  since  DECNET 


has  nc  session  layer ,  and  th6  remaining  layer,  the  applica- 
tion  layer,  is  a  mixture  of  the  ISO  presentation  and  appli¬ 
cation  layers. 

Apparently,  the  NS203  0  has  covered  both  network  and 
transport  layers,  thus,  the  only  layer  left  to  be  developed 
is  the  application  layer. 

1  •  1L  flSISlflBi&a  t&i  application  layer 

Bith  the  suggestion  from  the  NS2030  VAX/VHS  Device 
Driver  and  Diagnostic  Osar  Manual  [Ref.  5],  VAX-FORTRAN 
programming  language  is  chosen  to  be  used  in  developing  the 
applicaticn  layer.  the  other  reason  to  use  fortran  is 

because  of  the  provided  function  argument  of  QIO  service 

call  in  NIDEF.  FOB  file  in  the  Driver  Routine.  This  makes  it 
easier  for  the  programmer  to  issue  commands  to  the  NI1010 
Dnibus  Ethernet  Communications  Controller  Board.  Steps  in 
developing  application  layers  are  as  follows: 

1)  All  available  system  service  routines  in  VAX/VMS 
involving  I/O  operation  are  studied.  Some  of  the  very  impor¬ 
tant  routines  which  are  used  in  developing  the  program  are 
included  in  Appendix  A. 

2)  The  first  experiment  is  to  check  whether  the 

program  can  really  instruct  the  Nil 010  Board  what  tc  do. 

This  is  done  by  writing  a  program  that  will  send  out  a 
message  to  the  HI1010  Board  and  direct  the  board  to  send  the 
message  back  to  itself, i.e. ,  send  the  message  from  memory  to 
the  transmit  buffer  and  send  that  same  message  back  tc  the 
receive  buffer  of  NI1010  Board.  In  order  to  do  this,  the 
NI1010  Beard  must  be  put  in  the  INTERNAL  LOOP  BACK  NODE.  The 
detail  of  command  descriptions  available  to  be  used  with 
H1 1 0 1 0  Eoard  can  be  found  in  NI1010A  Unibus  Ethernet 
Communications  Controller  User  Manual  [Ref.  4].  The  program 
that  is  developed  for  this  experiment  is  included  in 
Appendix  B. 
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3)  The  seccnd  experiment  is  to  do  the  same  thing 
except  that  this  tine  the  message  will  be  sent  out  tc  the 
transceiver  and  onto  the  coax  cable*  but  the  Destination 
Address  field  contains  the  address  of  the  board  itself 
(02-07-01-00-07-7F)  *  thus  this  message  will  come  back  tc  the 
receive  buffer  again.  This  is  called  "EXTERNAL  LOOP  BACK 
BODE”. 

4) -  After  the  first  two  experiments  are  completed 
successfully*  the  Destination  Address  field  is  changed  to 
that  cf  the  NS3010  Beard  implemented  in  the  SDS  system.  He 
have  two  NS3010  Boards,  one  with  address  02-07-01-00-04-0A 
and  the  ether  with  address  02-07-01-00-03- EA. 

5)  The  next  step  is  to  transfer  a  file.  The  same 
type  of  experiment  which  has  been  done  in  sending  and 
receiving  the  message  is  used.  The  DOWNLOAD  and  OPLOAD 
procedure  in  the  VAX/VHS  are  studied.  All  the  FORT BAN 
statements  used  in  file  operation  can  be  found  in  VAX-11 
FORTRAN  User's  Guide  [Ref.  8]. 

2.  flgthoa  t£  Overcome  frame  §egueaslS3 

It  has  been  mentioned  earlier  that  the  NI1010  Eoard 
does  not  have  a  capability  to  preserve  the  order  of 
messages.  Therefore  the  design  of  the  application  layer 
protocol  shculd  take  this  matter  into  consideration. 

The  solution  is  that  the  convention  of  communicating 
between  any  two  computer  systems  should  be  made  such  that 
both  stations  will  be  able  to  know  each  other's  status.  The 
convention  cf  communicating  has  been  established  as  follows: 

a)  .The  receiving  station  will  send  an  acknowledge  message 
every  time  a  frame  is  received  successfully.  If  an 
error  should  occur,  no  acknowledge  message  will  be 
sent. 


b)  .The  sending  station  should  wait  for  the  acknowledge 

message  from  the  receiving  station  for  a  sufficient 
aacut  of  tiae  (protocol  in  7&X/VMS  is  set  up  for  5 
seconds),  if  there  is  no  acknowledge  message  within 
this  period  of  tiae  it  will  retransmit  the  same  frame 
again  and  wait  for  the  acknowledge  message.  The  same 
frame  is  transmitted  for  the  total  of  3  times  (  1  tran¬ 
smission  and  2  retransmissions)  before  the  transnit 
process  will  be  aborted. 

c)  .The  convention  used  to  differentiate  whether  the  frame 

is  carrying  a  message  or  a  file  is  established  by  the 
use  of  the  available  Type  field  (2  bytes)  of  each 
fraae.  It  has  been  set  up  as  shown  in  Table  I. 


Type  Field 

TABLB  I 

Protocol:  (All  in  Hezadeciaal) 

inn 

§1112 

FUNCTION 

00 

00 

console  message 

00 

FF 

acknowledge  message 

OF 

00 

file  transfer-first  frame 

OF 

01 

file  transfer-interned  fraae 

OF 

OF 

file  transfer-1  record  file 

OF 

FF 

file  transfer-last  frame 

D.  I  BP  LE  HE  STATION 


The  final  software  protocol  (application  layer  protcccl) 
whose  source  code  is  shown  in  Appendix  C  is  now  available  in 
VAX/ VMS  for  public  use.  This  program  is  in  the  file 
ETHEBNET .FOB.  A  user  who  wants  to  transfer  files  cr  messages 
between  VAX/VMS  and  BOS  systems  can  do  so  by  following  the 
instructions  given  in  VAX/VMS-NDS  Ethernet  local 
Communication  Network  User  Manual  included  in  Appendix  D. 


V.  COBCIOSIOB 


The  principal  goals  of  this  thesis  were  met.  The  devel¬ 
oped  software  protocol  was  tested  with  the  actual  transfer 
of  messages  and  files  between  VAX-11/780  under  VMS  operating 
system  and  MDS  System  under  CP/H-80  operating  system.  A 
file  as  large  as  43  Kbytes  was  transferred  roughly  in  less 
than  42  seconds. 

At  present,  the  program  is  available  in  VAX/VMS  public 
user  account  under  user  name  "INTERLAN"  with  password  "VMS". 
The  VAX/VHS-HDS  Ethernet  Local  Communication  Network  User 
Manual  is  also  available  in  the  file  "VNSMDS.DAT".  The 
content  in  this  file  is  exactly  the  same  as  the  content  in 
Appendix  E  in  this  thesis.  Users  who  want  to  do  the  message 
or  file  transfer  can  get  the  hard  copy  of  this  file  by 
simply  legging  into  the  VAX/VMS  under  user  name  and  password 
mentioned  above  and  printing  the  file.  Then  the  steps  in  the 
manual  must  be  followed. 

The  files  in  public  user  account  are: 

ETHEB1. FOR  (source  code) 

BTHEB1.  EXE  (executable  code) 

This  is  a  program  to  transfer  a  message  in  the  INTERNAL 
LOOPBACK  mode. 

Slices- for 

This  is  a  program  to  send  a  message,  typed  in  from  the 
terminal,  from  the  VAX/VMS  to  the  MDS  System.  It 
retransmits  the  same  message  3  times  with  the  interval 
of  5  seconds  before  the  transmit  process  is  aborted  if 
there  is  no  acknowledge  signal  from  the  receiving 
station. 
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GETHSG.F01 

SHS5S-I25 

This  prograa  waits  for  the  message  intended  for  the 
VAX/VMS.  It  sends  back  the  acknowledge  signal  tc  the 
sending  station  every  time  it  receives  a  frame  success¬ 
fully.  The  received  message  is  displayed  on  the  screen. 

DCWHICAD.FQ8 

DCWNICAD.EXE 

This  pregram  is  used  tc  transfer  a  specified  file  from 
VAX/VHS  to  ftDS  System.  It  will  wait  fer  an  acknowledge 
signal  from  the  receiving  station  after  every  frame  has 
been  transmitted.  The  same  frame  will  be  transmitted  3 
times  with  the  interval  of  5  seconds  before  the 
transmit  process  is  aborted,  if  there  is  no  acknowledge 
signal  from  the  receiving  station.  The  file  is  trans¬ 
ferred  by  a  record  of  128  bytes  so  it  would  match  the 
characteristics  cf  CP/H  records. 


DELOAI. FOB 
OfICAE.EXE 

lx  is  a  program  used  to  receive  the  incoming  file  from 
the  HDS  System.  It  sends  an  acknowledge  signal  tc  the 
sending  station  for  every  successfully  received  frame. 
This  program  puts  VAX/VHS  into  a  ready-to-receive-file 
mode  until  control-!  key  is  pressed. 

EIHEBSET.FOB 

ETHEESET.SXff 

This  prograa  is  a  combination  of  all  the  programs 
mentioned  above.  When  executed,  VAX/VHS  will  be  ready 
to  receive  any  message  in  the  network  which  is  intended 
for  the  VAX/VHS.  The  message  will  be  interpreted 
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whetker  it  is  a  ordinary  message,  a  request  transfer¬ 
ring  of  file,  or  a  reguest  receiving  of  file. 

1) .If  the  aessage  is  an  ordinary  message,  the 

program  prints  that  message  on  the  screen, 
sends  an  acknowledge  signal  to  the  sending 
station,  and  is  ready  to  receive  ancther 
message. 

2)  .If  the  message  is  a  request  for  transferring  a 

file,  the  program  sends  back  an  acknowledge 
signal  and  transfers  a  specified  file  to  the 
sending  station  until  the  whole  file  has  been 
transferred  successfully.  The  request  for 
transferring  a  file  message  should  include  the 
filename  and  filetype,  PN. FT,  of  the  file  which 
the  requesting  station  wants  to  receive.  If  the 
public  user  account  does  not  have  the  specified 
file,  acd  error  message  will  be  sent  to  the 
requesting  station  to  notify  the  user. 

3)  .If  the  received  message  is  a  request  for 

receiving  a  file,  the  program  will  send  an 
acknowledge  message  together  with  instructions 
to  the  user  of  the  requesting  station  to  open  a 
new  file  under  the  specified  FN. FT,  receive  the 
incoming  file  until  its  all  done,  then  send  a 
message  to  the  sending  station  that  the  whole 
file  has  been  received  successfully  and  then 
put  VAX/VHS  back  to  ready-to-receive-message 
mode. 

All  of  these  files  can  be  copied  by  any  users  by  typing 
the  following  commands: 


SCcpy 

morn:  _DRA1  :[  IHTERLAN  ]FN.FT 


i 
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$Tc: 


NFN.NFT 


where  FN.FT  is  the  filename. filetype  of  the  file  tc  be 
copied  frcm,  and  NFN.NFT  is  the  filename. filetype  of  the 
file  to  be  copied  to.  The  NFN.NFT  will  appear  in  the  user's 
directory  after  the  above  sequence  of  commands  have  been 
executed.  It  is  necessary  that  the  file  type  of  the  new  file 
should  be  the  same  as  the  old  file. 

Future  research  with  VAX/VMS  Ethernet  Software  Prctocol 
should  concentrate  on  trying  to  make  the  MDS  System  terminal 
act  like  a  virtual  terminal  of  VAX/VMS.  There  are  system 
service  routines  available  in  VAX/VMS  which  support  this 
capability.  Anyone  who  is  interested  to  do  a  further 
research  in  this  field  can  get  all  the  information  about 
these  routines  from  Mr. Albert  Bong,  VAX  professional  staff, 
in  Ha.  SP505.  The  modifications  can  be  made  without  any 
changes  in  the  present  programs  since  this  program  is 
designed  with  a  layering  concepts  of  the  network  protocol. 

Another  direction  of  research  is  to  expand  the  network 
so  that  VAX/VMS  can  also  communicate  with  other  systems 
under  different  operating  systems  such  as  ISIS  II  or 
MCOBTEX. 
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kUMSU  h 

VAX/VHS  STSTEH  SERVICE  ROUTINES 


The  followings  are  the  VAX/VMS  System  Service  Routines 
which  are  used  in  developing  the  application  layer  protocol 
for  the  Ethernet  Local  Area  Network. 

$  ASSIGN 

SASSIGN  -  ASSIGN  I/O  CHANNEL 

The  Assign  I/O  Channel  system  service  (1)  provides  a  process 
with  an  I/O  channel  so  that  input/output  operations  can  be 
performed  or  a  device,  or  (2)  establishes  a  logical  link 
with  a  remote  node  on  a  network. 

High-level  Language  Fermat 

STSIASSIGN  (devnam,chan,[  acmode  ],[  nbxnam  ]) 

devnam 

Address  of  character  string  descriptor  pointer  to  the 
device  name  string.  The  string  may  be  either  a  physical 
device  name  or  a  logical  name.  If  the  device  name 
contains  a  colon,  the  colon  and  rhe  characters  that 
fcllcw  it  are  ignorad.  If  the  first  character  in  the 
string  is  a  underscore  character^),  the  name  is 
considered  a  physical  device  name.  Otherwise,  the  name 
is  considered  a  logical  name  and  logical  name  transla¬ 
tion  is  performed  until  either  a  physical  device  name 
is  feund  or  the  system  default  number  of  translations 
has  been  performed. 

If  the  device  name  contains  a  double  colon  (::),  the 
system  assigns  a  channel  tc  the  first  available  netwerk 


device  (NET:)  and  performs  an  access  function  on  the 
network. 

chan 

Address  of  a  word  to  receive  the  assigned  channel 
number. 

acnode 

Access  mode  to  he  associated  with  the  channel.  The  most 
privileged  access  mode  used  is  the  access  mode  of  the 
caller.  I/O  operations  on  the  channel  can  only  be 
performed  from  equal  and  more  privileged  access  modes. 

mbznas 

Address  of  a  character  string  descriptor  pointing  to 
the  logical  name  string  for  the  mailbox  to  be  associ¬ 
ated  with  the  device,  if  any.  The  mailbox  receives 
status  informa ticn  from  the  device  driver. 

An  address  of  0  implies  no  mailbox;  this  is  the  default 
value. 

Notes 

1)  Fcr  details  on  how  to  use  $ASSIGN  in  conjunction  with 
network  operations,  see  the  DECnet-V AX  User*  s  Guide 
[Bef.  9]. 

2)  Only  the  owner  of  a  device  can  associate  a  mailbox 
with  the  device  (the  owner  is  the  process  that  has  allocated 
the  device,  either  ixplicitly  or  explicitly)  ,  and  only  one 
mailbox  can  be  associated  with  a  device  at  a  time.  If  a 
mailbcx  is  associated  with  a  device,  the  device  driver  can 
send  messages  containing  status  information  to  the  mailbcx, 
as  in  the  following  cases: 


a)  .If  the  device  is  a  terminal,  a  message  indicates 
dial-up,  hang-up,  or  the  reception  of  unsolicited 
i  n  pu  t . 

fc)  .If  the  target  is  on  a  network,  the  message  may 
indicate  that  the  network  is  connected  cr  initi¬ 
ated,  cr  whether  the  line  is  down. 

For  details  on  the  message  format  and  the  information 
returned,  see  the  VAX/VBS  User is  Guide  (Ref.  7]. 

3)  Channels  remain  assigned  until  they  are  explicitly 
deassigned  with  the  Deassign  I/O  Channel  (SDASSGN)  system 
service,  or,  if  they  are  user-mode  channels,  until  the  image 
that  assigned  the  channel  exits. 

4)  The  $  AS  SIGN  service  establishes  a  path  to  device,  but 
does  not  check  whether  the  caller  can  actually  perform 
input/output  operations  to  the  device.  Privilege  and  protec¬ 
tion  restrictions  may  be  applied  by  the  device  drivers.  For 
details  cn  hew  the  system  controls  access  to  devices,  see 
the  V1X/VBS  I^O  O^er 's  Guild  [Bef.  7]. 
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$QI0  W  -  QOEOE  I/O  REQUEST  A MO  HAIT  FOH  EVENT  FLAG 

Iha  Queue  I/O  Request  and  Wait  for  Event  Flag  system  service 
combines  the  $QIO  and  SHAITFR  (Wait  for  Single  Event  Flag) 
systea  services.  It  can  be  used  when  program  oust  wait  for 
I/O  completion. 

High-level  Language  Fermat 

SIS JQICH  ([  efn  ]  ,chan,  f  unc,[  iosb  ],[  astadr  ],  [astprm], 
CFn.CE2]#[p3],Cp4]#[p53,[p6]) 

efn 


Number  of  the  event  flag  that  is  to  be  set  at  request 
completion.  If  net  specified,  it  defaults  to  0. 

chan 


Number  of  the  I/O  channel  assigned  to  the  device  to 
which  the  request  is  directed. 

func 


Function  code  and  modifier  bits  that  specify  the  opera¬ 
tion  tc  be  performed.  The  code  is  expressed  symboli¬ 
cally. 

iosb 

Address  of  quadverd  I/O  status  block  that  is  tc  receive 
final  completion  status. 

astadr 

Address  of  the  entry  mask  of  an  AST  service  routine  to 
be  executed  when  the  I/O  completes.  If  specified,  the 
AST  routine  executes  at  the  access  mode  from  which  the 
$QI0  service  was  requested. 
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astprm 

1ST  parameter  to  be  passed  to  the  1ST  completion 
routine. 

pi  to  p6 

Cptional  device-  and  function-specific  I/O  request 
parameters. 

The  first  paraaeter  aay  be  specified  as  pi  or  plv, 
depending  cn  whether  the  function  code  requires  an 
address  or  a  value,  respectively.  If  the  keyword  is  cot 
used,  pi  is  the  default;  chat  is,  the  argument  is 
considered  an  address. 

E2  through  Pn  are  always  interpreted  as  values. 


Notes 

1)  The  specified  event  flag  is  set  if  the  service  termi¬ 
nates  without  queuing  an  I/O  request. 

2)  The  I/O  status  block  has  the  following  format; 


31  16  15 


BYTE  COUNT 

STATUS 

DEVICE-  AND  FUNCTION- 

DEPENDENT  INFORMATION 

a)  .status  -  completion  status  of  the  I/O  request. 

t).byte  count  -  Number  of  byte  actually  transferred. 
Note  that  fcr  some  devices  this  contains  only  the 
lew-order  word  of  the  count. 

c)  . device-  and  function-dependent  information  -  Varies 
according  to  device  and  operation  being  performed. 
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The  information  returned  for  each  device  and  func¬ 
tion  code  is  documented  in  the  VAX/VHS  I/O  User's 
Guide  [fief.  7]. 

3)  Hany  services  return  character  string  data  and  wri*e 
the  length  of  the  data  returned  in  a  word  provided  by  the 
caller.  Function  codes  for  the  JQIOB  system  service  (and 
the  LENGTH  arguaent  of  the  {OUTPUT  system  service)  require 
length  specifications  in  longwords  (32-bit  word).  If 
lengths  returned  by  ether  services  are  to  be  used  as  input 
parameters  for  IQIOW  requests,  a  longword  should  be  reserved 
to  ensure  that  no  error  occurs  when  $QIOW  reads  the  length. 

4)  For  information  on  perforaing  input  and  output  opera¬ 
tions  on  a  network,  see  the  DECnet-VAX  User's  Guide 

[Hef.  9]. 
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SBINTIHE  _  CONVERT  ASCII  STRING  TO  BINARY  TIME 

The  Convert  ASSCII  string  to  Binary  Time  systea  service 
converts  an  ASCII  string  to  an  absolute  or  delta  tine  value 
in  the  systea  64-bit  tiae  forest  suitable  for  input  to  the 
Set  Tiaer  (SSETIHB)  or  Schedule  Nakeup  ($ SCHDWK)  systea 
services. 

High-level  Language  Fcrnat 

SYSSEINTIM  (tiatuf  ,tiaadr) 
tiabuf 

Address  of  a  character  string  descriptor  pointing  to 
the  buffer  containing  the  absolute  or  delta  tiae  to  be 
converted.  The  required  foraat3  of  the  ASCII  strings 
are  described  in  the  Notes,  below. 

tiaadr 

Address  of  a  quadword  that  is  to  receive  the  converted 
tiae  it  64-bit  fcraat. 


Notes 

1)  The  SBINTIN  service  executes  at  the  access  aode  of 
the  caller  and  dees  net  check  whether  address  arguaents  are 
accessible  before  it  executes.  Therefore,  an  access  viola¬ 
tion  causes  an  exception  condition  if  the  input  buffer  or 
buffer  descriptor  cannot  be  read  or  the  output  buffer  cannot 
be  written. 

2)  This  service  does  not  check  the  length  of  the  argu- 
aent  list,  and  therefore  cannot  return  the  SS$_INSFARG 
(insufficient  arguaents)  error  status  code.  If  the  service 
does  net  receive  enough  arguaents  (for  exaaple,  if  one  oaits 
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required  commas  is  the  call) ,  one  night  not  get  the  desired 
result. 


3)  The  reguired  ASCII  input  strings  have  the  format: 
Absolute  Tine:  dd-*mm-yyyy  hh:nn:ss.cc 

Delta  Tine:  ddd  hh:nn:ss.cc 


XllU 

dd 

mnn 


length  (bytes)  Contents 


Banqe  of  values 


2 

1 

3 


day  of  month 
hy  phen 
month 


mik 

hh 


an 

ss 

cc 

dddd 


1 

4 

n 

2 

1 

2 

1 

2 

1 

2 


hy  phen 


year 
plank 


hour 
colon 
ninute 
colon 
second 
period 

hundredths  of 
se  cond 

nunber  of  days  000  -  9999 
(in  24 -hour  units) 


1  -  31 

Required  syntax 
JAN,  FEB ,  HAR,  APR, 
HAT ,  JUN  ,  JOI,  AUG, 
SEP,  OCT,  NOV,  DEC 
Required  syntax 
1858  -  9999 
Required  syntax 
00  -  23 

Required  syntax 
00  -  59 

Required  syntax 
00  -  59 

Required  syntax 
00  -  99 


Note  that  aonth  abbreviations  must  be  upper  case.  In 
contrast  vith  previous  versions  of  VAX/VHS,  the  hundredths 
of  second  field  nov  represents  a  true  fraction.  For  example, 
the  string  .1  represents  ten  hundredths  of  a  second  (one 
tenth  of  a  second)  ;  the  string  .01  represents  one  hundredth 
of  a  second.  Note  also  that  a  third  digit  can  be  added  to 
the  hundredths  of  second  field;  this  thousandths  of  second 
digit  is  used  to  round  the  hundredths  of  second  value. 
Digits  beyond  the  thousandths  of  second  digits  are  ignored. 


4)  The  following  syntax  rules  apply  to  specifying  the 
ASCII  input  string: 


a). Any  of  the  date  and  time  fields  can  be  omitted. 


Per  absolute  time  values,  the  SBINTIB  service 
supplies  the  current  system  date  and  time  for  nonspe- 
cified  fields.  Trailing  fields  can  be  truncated.  If 


-•  -• 
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leading  fields  are  omitted,  the  punctuation  (hyphens, 
blanks,  colons,  periods)  bust  be  specified.  For 
example,  the  following  string  results  in  an  absolute 
tiie  of  12:00  cn  the  current  day. 

_  12:00:00.00 

For  delta  tiae  values,  the  SBINTIH  service  defaults 
ncnspecified  hcurs,  minutes,  and  seconds  fields  to  0. 
Trailing  fields  can  be  truncated.  If  leading  fields 
are  caitted  froa  the  tiae  value,  the  punctuation 
(blanks,  colons,  periods)  aust  be  specified.  If  the 
nuaber  of  days  in  the  delta  tiae  is  0,  a  0  must  be 
specified.  Fcr  example,  the  following  string  results 
in  a  delta  tiae  of  10  seconds. 

0  :  :10 

Note  the  space  between  the  0  in  the  day  field  and  the 
twc  colons. 

b).Fcr  both  absolute  and  delta  tiae  values,  there  can 
be  any  nuaber  of  leading  blanks,  and  any  number  of 
blanks  between  fields  normally  deliaited  by  blanks. 
However,  there  can  be  no  eabedded  blanks  within 
either  the  date  or  tiae  fields. 

The  following  examples  illustrate  legal  input  strings  tc  the 
SBINTIH  systea  service,  and  the  tia9  represented  by  the 
output  frca  the  SBINTIH  systea  service  (translated  through 
the  Convert  Binary  Tiae  to  ASCII  string  (3&SCTIN)  systea 
service).  Assuae  that  the  current  date  is  14-JUN-1983 
04: 15:28.00. 

£ASCT£M  output  string 

1 4 -JON- 1983  04:50:28.00 
14-JUN-1984  00:00:00.00 
9-NOV-1982  12:32:01.12 


1&SJ21  is  uuxu 

—  :  50 

--1984  0:0:0. 0 

9-NO V-1 982  12:32: 1.1 161 
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$ SETIBH  -  SET  TIHEE 

The  Set  Tiaer  systei  service  allows  a  process  to  schedule 
the  setting  of  an  event  flag  and/or  the  queuing  of  an  AST  at 
soee  future  tine.  The  tiae  of  the  event  can  be  specified  as 
a  absolute  tiae  or  as  a  delta  tiae. 

flhen  the  service  is  invoked,  rhe  event  flag  is  cleared 
(event  flag  0,  if  none  is  specified). 

High-level  language  Fcraat 

STSSSETIHH  ([ef  n  1  ,daytia  ,[astadr]  ,[reqidt]) 

efn 


Event  flag  nuaber  of  the  event  flag  to  set  when  the 
tiae  interval  expires.  If  not  specified,  it  defaults  to 
0. 

daytia 

Address  of  the  guadword  expiration  tiae.  A  positive 
tine  value  indicates  an  absolute  tiae  at  which  the 
tiaer  is  to  expire.  A  negative  tiae  value  indicates  an 
offset  (delta  tine)  froa  the  current  tiae. 

astadr 

Address  of  the  entry  aask  of  a  AST  service  routine  to 
be  called  when  the  tiae  interval  expires.  If  not  speci¬ 
fied,  it  defaults  to  0,  indicating  no  AST  is  to  be 
queued. 

reqidt 

Nuaber  indicating  a  request  identification.  If  not 
specified,  it  defaults  to  0.  A  unique  request 


identification  can  be  specified  in  each  set  *imer 
requests,  or  tfce  same  identification  can  be  given  to 
related  timer  requests.  The  identification  car.  be  used 
later  to  cancel  the  tiaer  request(s).  If  an  AST  service 
routine  is  specified,  the  identification  is  passed  as 
the  AST  parameter. 

Notes 

1)  The  access  acde  of  the  caller  is  the  access  mcde  of 
the  request  and  cf  the  AST. 

2)  If  a  specified  absolute  time  value  has  already 
passed,  the  tiaer  expires  at  the  next  clock  cycle  (that  is, 
eithin  10  Billiseconds). 

3)  The  Convert  ASCII  String  to  Binary  Time  (SEINTIH) 
system  service  converts  a  specified  ASCII  string  to  the 
quadwcrd  time  format  required  as  input  to  the  3SETIMR 
service. 


78 


man 


JWAITFR  -  WAIT  FOR  SINGLE  EVENT  FLAG 

The  Bait  for  Single  Event  Flag  system  service  tests  a 
specific  event  flag  and  returns  immediately  if  the  flag  is 
set.  Otherwise,  the  process  is  placed  in  a  wait  state  until 
the  event  flag  is  set. 

High-level  Language  Fermat 

SYSIWAITFR  (efn) 


efn 


Number  of  the  event  flag  for  which  to  wait. 


Notes 

The  wait  state  caused  by  this  service  can  be  interrupted 
by  an  asynchronous  system  trap  (AST)  if  (1)  the  access  mode 
at  which  the  AST  executes  is  more  privileged  than  or  equal 
in  privilege  to  the  access  mode  from  which  the  wait  was 
issued  and  (2)  the  process  is  enabled  for  ASTs  at  that 
access  mode. 


When  the  AST  service  routine  completes  execution,  the  system 
repeats  the  JWAITFR  request.  If  the  event  flag  has  been  set, 
the  pzccess  resumes  execution. 
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ICANTIM  “  CANCEL  TIMES 

The  Cancel  Timer  Bequest  system  service  cancels  all  or  a 
selected  subset  cf  the  Set  Timer  requests  previously  issued 
by  the  current  image  executing  in  a  process.  Cancellation  is 
based  cn  the  request  identification  specified  in  the  Set 
Timer  (SSETIHB)  system  service.  If  more  than  one  timer 
request  eas  given  to  the  same  request  identification,  they 
are  all  canceled. 

High-level  Language  Format 

SYSSCANUM  ([regidt]  ,  [acnode]) 

reqidt 

Bequest  identification  of  the  timer  request  (s)  to  be 
canceled.  A  value  of  0  (the  default)  indicates  that  all 
timer  requests  are  to  be  canceled. 

acmode 

Access  mode  of  the  request ( s)  to  be  canceled.  The  mcst 
privileged  access  mode  used  is  the  access  node  of  the 
caller.  Only  those  timer  requests  issued  from  an 
access  node  equal  to  or  less  privileged  than  the  resul¬ 
tant  access  mode  are  canceled. 


Notes 

Outstanding  timer  requests  are  automatically  canceled  at 
image  exit. 


APPENDIX  B 

SOOBCE  CODE  FOB  EXPEBIBEHTS 


All  the  source  cede  in  this  appendix  was  developed  from 
the  step-by-step  design  of  the  Ethernet  software  Protocol. 
Each  cf  the  programs  includes  a  brief  explanation  of  the 
function  when  it  is  executed. 


PPOGPAM  ETHEPt 


TRANSFER  mESSAGE/INTERMAL  LOOPBACK. 


character*26 
i nteoer *2 
i nt  eaer 
include 
i nc 1 ude 
byte 


text  /'This  nessaae  will  be  sent.'/ 
i osd ( 2  ) 

nic^an,  svsfaiow,  svsSassinn 
’  «-dr  aO :  fnnssys.interlanl  nidef.for* 

' (Hiodef )  ' 

Toac k et ( 1 36 ) ,  Roac ket ( 1 46) 


Assign  destination  address: 
Toacket ( t )  =  *  02 '  x 
Toacket (2)=' 07' x 
Toacket ( 3 )  = ' 0 1  '  x 
Toacket  (4)  =  ' 00  '  x 
Toacket (5)='07'x 
Toac  k  »t  ( 6  )  =  '  7F  1  x 


Tyoe  assionment :  0000=tso,  etc. 
Toacket (7)  =  'C0'  x 
T oac ket(8)='00'x 


Put  data  into  transmit  oacket: 
i=P 

do  i = 1 , 26 

Toacket ( i )=icharCtext(i 
j s  i  1 1 


end 

do 


1=35,1 36 

Toacketf I )  =  *  00  ' 


x 


end  do 


i  )  ) 


Assiqn  a  channel  to  *JIA0: 

istat  =  sys$assian( '  NI A0 ’ »  n i chan , ,  ) 
if(.not.istat)  call  libSstoo(%val(istat)) 
tyoe  A  i st at= ' , i stat 

Start  uo  and  ao  on  line: 

istat=  sy stqi ow ( , %va 1 ( n i c ban ) , 

1  %va  1  ( i  o5«-set  Tode  .or.  i  oSn«-s  t  a  r  t  uo ) 

2.  ioso 

i f ( .not . i st at )  call  1 i bis t oo ( %va 1  C i st at )  ) 
if(iosb(l).ne.l)  call  1ibistoo(%val(iosb(l))) 
tyoe  S  i stat  =  ' , i stat ,  '  S  i osb H )  =  ' , i osb ( 1 ) 


Internal  looooack: 

i st at =sys 5oi ow C , Uva 1 (nichan), 

1  XvaHioP^siln), 

2  i  050  i  m  (  »  f  r  i  ) 

i f ( .not . i st at )  call  1 i b is t oo C £v a  1  ( i s t a t ) ) 
i f C i osb ( 1 ) . ne • 1 )  call  1 i bis t oo ( Xv a  1 ( i osb ( 1 ) 1 ) 
tyoe  I  i stat= ' , i stat , '  T  i oso ( 1 ) = * , i osb ( 1 ) 


°  r  o<r  i  scuous: 

istat=svsiaiow(,%val (nichan), 

1  Xval(io«"*’sornr>)f 

2  iOSDrtrrrtrr) 

if(.  not.  i  stat)  call  lib5stoo(*ival(istat)) 
i f ( i osb ( 1 ) . ne . 1 )  call  1 i bfs t oo f % va 1 C i osd ( 1 ) ) > 


Receive  on  error : 

istat=sys$aio*(#%val ( n i ch  an ) , 

1  %va1(io*-^sroeit)» 

2  i osb# ,  , ,  , ,  ,  ,  ) 

i f ( .not . i st at )  call  1 i b J st od ( %v a  1 ( i s t at ) ) 
i f ( i osb ( 1 ) .ne . 1 )  call  H b$st oo ( % va 1 ( i osb C 1 ) ) ) 

T ransfni  t  oacket  : 

istat=sys3aiow(#2val ( n i c  han ) » 

1  %  va  1  ( i  o  *  *■*  p  i  t  e  1  o  1  k  )  # 

2  i osb , , , 

3  %  re f ( Toac kef ) , % v a 1( 1 36 ) , , , , ) 
if(.not.istat)  call  !ib'5stoD(%val(istat)> 
if(iosb(l).ne.l)  call  lib.tstoo(%va1(iosn(l))) 
tyoe  *»’  T  i st at = * , i st at , '  T  i osb ( 1 ) = ' » i osb ( 1 ) 
tvoe  **  Toacket 

Load  transmit  lata  and  send: 

istat=sysBqiowC/%val (  n  i  c  h  an  )  , 

1  %  va  1  ( i  o«-«- 1  t  d)  f 

2  i oso , , , 

3  %  re*  (  Toac  k  et  )  »  X  v  a  1  ( 1  36  ) ,  ,  ,  ,  ) 

if(.not.  istat)  call  1 i o^ s t od ( X va 1 ( i s t a t ) ) 
tyoe  ^essaqe  is  beino  transmitted....' 

Receive  same  oacket: 

type  *#'  start  recei vino' 
istatssvs'Baiowf/Xval  (nichan)/ 

1  va  1  ( i  oHread  1  b  1  k  )  # 

2  i osb# , , 

3  %  ref ( Roae ket ) » %va 1 ( 1 1 » » » #  ) 

tyoe  *,  '  i osb (2) = ' , i osb (2) 

i f ( .not . i stat )  call  1 i b$s t oo ( Zv a  1 C i s t a t ) ) 
i f ( i  osb ( 1 ) . ne . 1 )  call  1 i b*stoD(*val ( i osb C 1 ) ) ) 
tyoe  *»'  R  istat='#istat#’  R  iosb(1)='»iosb(l) 
tvoe  *#Roacket 
i  =19 

do  *hile  (Roacket ( i ) .ne. i char C ' . ' ) ) 
tyoe  *#char (Roacket ( i ) ) 
i  =  i  >  1 

end  do 
call  exit 


nnnnn 


PROGRAM  SENDMSG 


c 

10 

c 


c 


c 

20 


1 1 


22 

C 


C 


ACTUAL  SEND  I  MG  OF  MESSAGE. 

WAIT  FOR  ACKNOWLEDGE  * 

IF  NOT  ACKNOWLEDGE  IN  5  SEC,  RETRANSMIT. 

IF  NOT  ACKNOWLEDGE  IN  10  SEC,  ABORT  TRANSMISSION. 


external 
i n t  eger  *  2 
i  nt  eqer*'4 
i nt  eqer  *  4 
i nt  eqer *4 
include 
i nc l ude 
bvt  e 
byte 


aoort 

i oso ( 2 ) , addr 

n  i  c  h  a  n  ,  svsSoiow,  sysSassion 
sysibintim,  sysfisetimr,  sysfiwaitfr 
svst  i  iie  ( 2 )  ,  t  i  me  ( 2) 

*  «-dr  aO :  Inossys. inter!  anl  n i de  f . f or ' 

•modef)' 

oad ( 1 00  ) 

Tnacke*1  (  1  36)  ,  text  ( 1  2S)  ,  R oac  Kef  (  150) 


Assian  a  channel  to  NIAO: 

istat=svs3assign( 'NIAO' , n i c  han ,  »  ) 
if(.not.istat)  call  1ibBstoo(%val(istat)) 


Start  uo  and  oo  on  line: 

istat=sys$niow(»2val (nichan), 

1  Kt/a  I  ( i  o  Besetmode  .or.  i  o  Bm*s  t  a  r  t  uo )  , 

2  i oso  ,  ,,,,,,,) 

i f ( . not . i st at )  call  1 i b£stoo( %va 1 ( i st at )  ) 
i f ( i osb ( 1 ) . ne  •  1  )  call  libBstoo(%val(iosb(l))) 


Assign  destination  address: 
Toacket  (1  )  =  *  02‘  x 
T oac  ket ( 2 )  =  *  07  *  x 
T  oac  ket (  3 )  =  ’  0  1  •  x 
T oac  ket ( 4 ) ~ *  0  0  * x 


Interact  with  user: 

tyoe  *,  *  Select  Net  Address  of 

tvoe  *,  *  M0S  System  00-04-0 A  : 

type  *,  ’  MDS  System  00-03-EA  : 

read(5, l 1 )addr 
fomat  (a  1  ) 

if  ( addr .eq. 1 1 ' )  then 

Toac  ket ( 5 ) = ' 04  '  x 
T packet ( 6  )  =  ’  0  A  '  * 
else  if  ( addr ,eo. ' 2 ' )  then 
T  oac  ket(5)  =  '03'x 
Toacket ( 6 )  =  ' E A  '  x 

e  1  se 


aoto  20 


end  i  f 

tvoe  *,  'Input  messaqe(l2S  char 
read ( 5, 22 ) t  ex  t 
f ornat ( 1 20a  1 ) 


Dest i nat i on 
tvoe " 1  "  ' 
type"?" ' 


max) end  with 


I 


Assign  t  yoe  field: 

Toacket(7)='00'x  1  indicate  that  it  is  a  message 

Toac ket ( 0 )=' 0 0 ' x  1  don’t  care 


Put  data  into  transmit  oacket: 
j=R 

do  i si , 28 

Toacket ( j )  =  t  e  x  t  (i  ) 


84 


end  do 


j  =  j  +  l 


T ransmi  t  oacket  : 

istat=svs$aiow(*%va1  (nichan)# 

1  %val(io$*,writelblk)f 

2  i osb , I , 

3  Xref ( Toacket ) f Xval ( 1 36) , » f » ) 

ifCiosb(l).lt.O)  cal)  I  ibSatooUval  Mosb(i  )  )) 
i f ( i osb ( 2) .ne. 0 )  cal)  j i b$s t oo ( X va I ( i osb f 2 ) ) ) 
tyDe  *»'  ^essaqe  is  beinq  t  ransmi  t  ted . 1 

Load  transmit  data  and  send: 

i  stat=svsSaiow(  #  va  1  ( n i c  han ) , 

1  %va  1  (  i  o*-<- 1 1  ds  ) » 

2  i  OSDr  f  m  /  i  f  r  ) 

i  f ( i osb ( t ) . 1 f  .  0  )  call  1  i  b? s t on ( %va 1 fi osb  (1  )  )  ) 
i  f ( i osb ( 2 ) . ne . 0  )  call  1 i b f s t oo ( X va 1 C i osb ( 2 ) )  ) 

mait  for  10  seconds  and  abort: 

call  sys$bintim('0  ::10.0',time) 
call  sysSset i mr (# t i me / abort r  ) 

aait  for  5  second  and  retransmit: 

call  svs*bi nt i m ( *  0  : : 5 . 0 ' , s vst i me )  I  retransmit 
call  svs$set i mr ( 1 t syst i me t  t  )  1  after  S  sec 

Receive  acknowledge: 

istatssvsSaiowif^val ( n i c  h  an  ) , 

1  %val ( i oS^readl bl < ) , 

2  i osb  t  >  * 

3  %ref (Roacket ) »%val ( 150) , , , , ) 
i f C i osb ( 1) . 1 t . 0 )  call  1 i bSst od ( S va 1 ( i osb ( 1 ) ) ) 
i f ( i osb ( 2 ) . ne . 0  )  call  1ib$stoo(%val(iosb(2))) 

Check  the  second  tyoe  field  if  =  FF  he*: 
if  (Roacket ( 1 3) .ea. 'FF' * )  then 
i  =  19 

do  while  (Roacket ( i ) .ne . i char (' % ') ) 
i  =  i  M 

end  do 

write(6*33)(Roacket(j)»i=19,i-l) 
format ( 1  ' >  < i >a 1 ) 

call  sys?cantim(  ,  )  1  cancel  timer 

Roacket(  1 }  =  1 00  '  x 
aoto  20 

end  i  f 

call  svsSwaitfr(l) 
aoto  30 


cancel  timer 


end 

call 

aoto 

end 


ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc 


SUBROUTINE  ARORT 


wri t  e ( 6 »  222 ) 

format ( '  Abort 
call  exit 
end 


Transmission') 


nnnn 


program  getmsg 


ACTUAL  RECEIVING  OF  MESSAGE. 

SEND  8ACK  ACKNOWLEDGE  MSr,.(2nd  tvo»  fieldrFF  o»x). 

IF  RECEIVED  3 AD  FRAME,  DO  NOTHING  3UT  WAIT  TO  wgcEIVE 


character*?3 

i  nt  eqer *2 

i  nt«qef*4 

i nc 1 ude 

include 

byte 

byte 

byte 


usul/'  Receive  success f u 1 1 v  .  * ' / 
i  o  s  b  C  2  ) 

nichan,  svsSaiow,  svsBassign 
'  «-dr  aO :  [nossys.interl  anl  nioef.for' 
' ( S i ode  f ) 1 
oad(lOO) 

Roacket(150),Toacket(13r>) 
df  i 1nam(A0),sH lnam(AO) 


Assign  a  channel  to  NIAO; 

istatssys5assiqn( 'NIAO' , n i c  han  » • ) 
i f(. not. is* at)  tyoe  * ,  *  Assign  error! 1 

Start  uo  and  qo  on  line: 

i  s  t  a  t  =  Syssqiow(,%val(nichan), 

1  X  va  1  ( i  o  S«-se  t  node  .or.  i  o?n«*st  artuo)  , 

2  i o  s  b  ) 

i f ( .not . i st at )  tyoe  *»'  Istat  start  uo  error! ' 
if(iosbCl).lt.O)  tyoe  *»  '  Start  uo  error! ' 

Receive  incominq  messaae: 

tyoe  *»  '  Ready  to  receive . ' 

istat=sysSqiow(,%val (nichan), 

1  2val  ( i  o$«-readl  n  1  k  ) , 

2  i osb, t  t 

3  Xr» f (Rdsc ket ) , X v a  1 f 1 50  )  ,  ,  ,  ,  ) 
i  f ( . not . istat)  then 

tyoe  Send  usq  istat  receive  error" 

goto  10 

end  i  f 

i  f ( i osb ( 1 ) . 1 t . 0 )  then 

tyoe  *»'  Send  msq  VAX/VMS  receive  error’ 
aoto  10 

end . i f 

i f ( i osb ( 2 ) .ea. 1 )  then 

tyoe  *#'  Send  usa  receive  block  CRC  error' 
qoto  10 

end . i f 

i  f  ( i osb ( 2 ) . eq. 2 )  then 

tyoe  Receive  block  alignment  error' 

goto  10 

end  i  f 

i f ( i osb ( 2 ) .eo.4 )  then 

tyoe  *#'  Send  uso  i>i  ssina  receive  block' 
qoto  10 

end . i f 

i f ( i osb (?) *ea. 1 7 )  then 

tyoe  '  Seno  n.sq  O^A  received  block  fail' 
qoto  10 

end  i  f 
i  =  1  q 

do  while  ( Roac ke t ( i ) . ne . i c ha r ( ' ' ' ) ) 
i  =  i  1 1 

end  do 

wri te(6, 1 1 ) (Roacket (j),i=lR,i-t) 


1 1 
c 

c 

c 

c 

c 


format  ( '  ' »<i >al ) 

tyoe  **'  Received  successful lv. 

Assign  destination  address: 

Toacket  ( 1 ) = ' 02 ' x 
Toacket (2)=*07’x 
Toacket (3)  =  *01  *x  , 

ToacketfajsRoacket ( 14) 
Toacket(5)=Roacket(lc5) 

Toacket (6)2Roacket ( lb) 


Assign  fvoe  field:  .  .  . 

Toacket (7)  =  ' 00  '  x  1  indicate  that  it  is  a  message 
Toacket (8)='FF ' x  1  acknowledae  signal 

out  data  into  transmit  Dacket: 

A=9-  23 

'  Toacket(i)=icnar(msqlfi:i)) 
j  =  j  +1 

end  do 

Transmit  oacket:  ,  ,  .  u  . 

i s t a t =s vs 3g i ow ( / L v a  1 f n i c n an ) , 

1  % v  a  1  ( i  o  $«*w  r  i  t  e  1  o  1  k  ) » 

2  iosb»i »  . 

3  %ref (Toacket )*%val  (t3e>)**f») 
ifCiosb(l).lt.O)  call  HbSstooCXval  ( i oso ( 1 ) ) ) 


t  yoe 


Acknowledge  is  being  transmitted. 


Load  transmit  data  and  send: 

istat=sys$aiow(*%val (nichan), 
t  % v a  1  ( i  o*-«- 1 1  ds  ) » 

2  ios6»> i > i >  m ) 

if (iosb(l).lt.O)  t  voe  ♦#’  Ether  xmit 
i f(iosb(2) . n e . 0 )  tvoe  Controller 

goto  10 
end 


error  1  ' 

xmi t  error  1  ' 


PROGRAM  UPLOAD 

ACTUAL  RECEIVING  OF  FILE. 

DISCARO  LAST  F=>A*F. 

CHECK  FOR  1  RECOPD  RILE. 

SEND  SACK  ACKNOWLEDGE  MSG.(2nd  tyoe  fieli=pF  ho*). 

IF  RECEIVE  BAD  FRAME,  DO  NOTHING  B'JT  WAIT  TO  receive 
SAME  FRAviE  AGAIN. 


character*?4* 
i n  t eqer *2 
i nt  eqer *4 
i nc I ude 
i nc I ude 
byte 
byte 
byte 


msql/*  Received  successfully.''/ 
i osn ( 2 ) , done 

nichan,  sysBoio*,  sysSassiqn 
'*-draO:lnossvs.interlanlnidef.for' 
* ( Siodef ) ' 
nad ( 100) 

Roacket(lSO),dfi  1  n  a  m  (  4  0  ) 

Toacket (13b) 


Assiqn  a  channel  to  NIAO: 

istat=svs5assiqn(  1  N  I  A  0  '  , n i c  h  an ,  ,  ) 
i f ( .not . i st at )  call  1  i b Bst oo ( X va 1 ( i st at )  ) 


Start  uo  and  do  on  line: 

i  s  t  a  t  =  Sys$qiow(,%va1 (nichan), 

1  £va  1  ( i  o?*-set  node  .or.  i  o$m*-s  t  ar  t  uo )  , 

2  i osb, ,»,»,»,  ) 

if(.not.istat)  call  1  ibistnoHival  ( i  stat ) ) 

i f ( i osb ( 1 ) . 1 t . 0 )  call  1 i b Bs t oo ( X va 1 ( i osb M ) ) ) 

i f ( i osb ( 2 ) . ne . 0 )  tyoe  *» 'Control ler  Start  uo  error' 

Initialize  flaq: 
done=0 

Interact  with  user: 

tyoe  Destination  filename?' 

read(5,52)1n,dfi In am 
dfi lnam(ln+l )  =0 
format  (q,  40al  ) 

ooen(name=dfi lnam,unit=2»orqaniz3tion='sequential  '  , 
l  tyoe=  new' ,carri aqecont  rol=*list',iostat=ios,err=7) 
aoto  10 


tyoe  *,  Ooen  file  fail! 
call  1 i b$s t on (%v a  1 ( i os ) ) 
qoto  2 


aoa  i  n 


Recei ve  file: 

tvoe  *»'  Ready  to  receive....' 
istat=svs$qiow(,%va1 (nichan)r 
t  %val  (  i  oS«*re3dl  bl  k  )  , 

2  i osb  ,  , , 

3  %  re f ( Roac ket ) , X va 1 ( 1  SO ) , , , , ) 
if(.not.istat)  call  libSstoo(%val(istat)) 

i f ( i osb ( 1 ) . 1 t . 0 )  call  1 i b ?s t oo ( Xval ( i oso ( 1 ) ) ) 


i f (iosb(2) .ne.O)  tyoe 


( Roac k e t ( I B ) . eo . ' OF ' x )  then 
write(?,550) (RoacketC  j ) 


Control  lor 


done  = 1 
ooto  40 

end  i  f. 

if  (Rnacket ( 1 3 ) 
done= 1 


!  ler  Receive  error' 
!  a  1  record  file 
5=19,146) 


then 


88 


‘A 


»% 

S 


& 


550 

C 

40 


50 


aoto  4  0 

Ip?  te(2*550)  (Roacket  ( j ) r i = t R , 146 ) 
fomat  C  1 2  8  a  1 ) 

Assign  destination  address: 

ToackefT 1 ) = ' 6 2 ' x 

Toacket (2)=t 07' x 
Toacket ( 5 )  = '  0 1  '  x 
Toacket ( 4 ) =Roacket ( 1 4 ) 

Toacket ( 5 ) =Roac  kef ( 15) 

Toacket (6)=Roacket ( 16) 

Ass i an  tyoe  field: 

Toacket (7)=' 00 ' x  i  indicate  that  it  is  a  message 
Toac ket ( 8 ) = ‘ FF ' x  1  acknowledge  sianal 

Put  data  into  transmit  racket: 
i=9._  24 

’  Toacket (i)  =  ichar(msg l  (i:i)) 
i  =  jtl 

end  do 

T  ransmi t  oacket  S  ,  .  .  , 

i st at =svs5qi ox ( t 4va 1 ( n i c han ) , 

1  %  v  a  1  (  io$«-write1o)k), 

2  i osb»  #  #  _  ^ 

3  %  re f ( Toac ke t ) > 4va 1 ( 1 5b ) f  » » * ) 

i f ( i osb ( 1 ) . 1 t . 0 )  call  1 i b$$too(%va1 ( iosb( 1 ) ) )  f 
tvoe  *» '  Acknowledge  is  being  transmitted . 

Load  transmit  data  and  send: 

istatssysSoiowCf^valCnichan), 

1  %va 1 ( i  o+*"  1 1  ds )  t 

2  i osbf  > ; f » » » # )  ..  . 

i  f  (  i  osb ( 1 ) . 1 f . 0 )  tyoe  *,*  Ether  xmit  error'. _ 

i f ( iosb(2) .ne.0)  tyoe  *»'  Controller  xmit  error! 
if  (done. eg. 1)  goto  50 
goto  20 


c 1 ose (uni t  =2 ) 
type  *t  '  Receive 
call  exit 
end 


comol ated ! 


r, 

I 

£ 

n 


*• 


! 


89 


nnnn 
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C 


C 


c 


c 

10 


11 


c 


c 

c 

20 


PROGRAM  D0WNL0A0 


ACTUAL  TRANSFER  F I IE / 1 N T ER AC T T VE  . 

RETRANSMIT  SAME  FRAME  I F  NO  ACKNOWLEDGE  IN  5  SEC. 

ABORT  TRANSMISSION  IF  NOT  RECEIVE  ACKNOWLEDGE  IN  1)  SEC. 


external 
i nt  eaer *2 
i nteaer*A 
i  nt  sger*4 
i nc I ude 
i  r>c  1  ude 
byte 
byte 
byte 


abort 

ioso(2)»  addr,  count »  Non® 

n  i  c  h  a  n  ,  s  y  S  $  q  i  o  w  #  svsSassiqn  * 

time(2)»systi-ne(2)»sec(?) 

'  «-dra0  :  [nossvs.interl anJ  nidef.for* 
' (Siodef ) ' 
oad ( 100) 

Toacket(136),sfi 1 nam( 40 ) 

Roac  ket ( 1 50  ) 


As  si  an  a  channel  to  'HAD: 

istat=sysiassiqn(  ' M I A0  '  rnicnan,  ,  ) 
if(.not.istat)  call  libSstoo(%va1(istat)) 


Start  uo  and  oo  on  line: 

istat  =  s v s Sqi ow ( , X va 1 ( n i c n an ) , 

1  «Jva  1  ( i  o?«-set  to  j»  .or.  i  o$m*s  t  a  r  t  uo )  , 

2  i osb »  »  t  t  •  •  ,  t  ) 

i  f ( . not • i st at )  call  1 i b Ss t oo C %v a  1 f i st a t ) ) 

i f < i osb C 1 ) . 1 t • 0 )  call  l i bSs t oo C Xva 1 ( i oso  ( 1 ) ) ) 

i f ( i osb ( 2 ) ,ne . 0 )  tvoe  * > ' Cont ro 1 1 er  Start  uo  error* 


Assign  destination 
Toac ket ( 1 )  =  ' 02 *  x 
Toacket (2)=’07* x 
Toac  ket ( 3 )  =  *  0 1  '  x 
Toacket (4)  =  *  00  » x 


address : 


Interact  with  user: 

type  Select  Net  Address  of  Destination:' 

type  *»  '  M0S  System  Q0-Q4-0A  :  tyoe"l"' 

type  MOS  System  09-03-EA  :  tyoe"2"' 

read(5# 1 1 )addr 
format ( a  1  ) 

if  (addr ,ea. '  1  '  )  then 

Toacket  (5  )  =  '  0'4  ’  * 

Toac  ket ( 6 )  =  *  0  A  ’  x 
else  if  ( addr .ea . ' 2 ' )  then 
Toacket.(5)  =  *03'  x 
Toacket ( b)  =  ' E  A • x 

el  se 

qoto  10 

end  i  f 


Assign  t  yoe  field: 

Toac  ket  ( 7 )  =  ' OF ' x 

Toac k e t ( 8 ) = ' 0 0 ' x  i  first  frame  rec i n ( 0 1 =00  hex 

Initialize  flaa: 
done  =  0 

Interact  with  user: 

tyoe  *, '  Source  filename?' 
read(5*22)ln,sfi Inam 
S  f i 1 nam ( 1 n> 1 ) =0 


90 


22 

9 

C 

30 

33 

40 


c 


c 

c 

c 

c 


c 


101 


format (g» 40al )  .  .  .  ,, 

ooen  ( name=s  f  i  1  nan  runit  =  l»oPoamzation-  seauePtiai 
1  #  t  yoe=  ' ol d ' #  c  ar r i  aaecont  ro  1  =  list '  >«rr  =  q) 

qoto  30  .  _  .  , 

tyoe  *•  *  No  Such  file!  Try  aaam 
goto  20 

Transmit  Packet: 

read(?»33»iostat=ios»end=100,err=101) 

1  (Toacket  ( j ) »  ]  =<?,  1  3b) 
format  (  1 28a 1 ) 

i st at =svsSqi ow( # Xval (ni chan) , 

1  X va 1 ( i o $*w r t t e 1 o 1 k 1 » 

2  t  OSv)  f  #  r 

3  %re f ( Toac ket ) » %y a  1 ( 1 3b ) » * » # ) 

if Ciosb(l).lt.O)  call  1 i b3s t oo ( %va1 C i osb ( 1) )) 
i f  C i osb (2) . n»  .  0 )  t  yoe  ' Controller  Transmit  error 
type  *»•  pile  is  oeing  transmitted . 

Load  transmit  data  and  send  file: 
istat.ssysSaio*(*Xval  tnic^anl  f 

1  Xval  (  i  o*'*,l  tds) » 

2  i osd 1 1 1 1  t  •  »  t  ) 


i f ( i osb( 1 )  .  1 t  .0 )  tyoe  *», 
i f ( i o$b(2) .ne.O )  tyoe  * 


*•'  System  xmit  errorl* 

»-  Controller  Xmit  error! ' 


A'ait  for  20  seconds  and  abort: 

call  sysfointim(  0  ::20.0'»sec) 
call  sysSset i mr (/ sec » abort » ) 

.lait  for  10  seconds  and  abort: 

call  sysSbi nf i m( ' 0  :  : l 0 . 0 • , 1 1 me ) 

call  sy sSset i mr ( 2 » t i mer / ) 

/fait  for  5  second  and  retransmit:, 

call  sysSbintimC '0  : : 5 . 0 ’ , sy st i me) 
call  sysSset i mr ( 1 # svst i me» » )  : 

Receive  acknowledge* 

istat=sys$giow(»!£vs1  (nichan)» 


!  wait  for 
acknowledge  5 


sec 


1 

2 
3 


%va 1 (ioiereadlblk), 
i osb  $  r  f 

XrefCRoacketlr^yal (I50)»f,») 


Check  the  second  tyoe  field  if  =  hex: 

if  (Roacket ( 1 3 ) ,eo. ' FF * x )  then 
call  sys 3c ant i m ( , ) 

Roacket ( 1 3)  =  '  00  '  x 
i f ( done . eo. 1 )  goto  50 
Toacket ( 81  =  *  0  1  '  x 
goto  30 

end  if 

if  (count. ne. 2)  then 

call  sy s  3 wa i t  f  r (  l ) 
count  =count ♦ 1 
goto  40 

end  ’ f  . 

call  sysSwaitfr(2) 

call  exit 

call  l ibSstoo(Xval( ios) ) 


cancel  timers, 
clear  flag 


i  middle  f  rame 
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*  v  o 


Assign  value  to  end  messaqe: 
do  i -9, 1 36 

Toac  ket ( i )  =  ' 32 ' x 

end  do 

T  oac  ket ( 8 ) s ' FF ' x 
done  =  1 
goto  40 

type  *r '  Transmit  comoleted' 
c 1 ose (uni t  =  1 ) 
goto  10 
end 


1  blank  cHar 
1  1 ast  f rame 


cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc 

SUBROUTINE  APQOT 
wri t  e ( b , 222 ) 

222  fonat  (  '  Aoort  Transmission') 

call  exit 
end 


-\»’s .  *  •’*  »’• . 
u\  «w*  ^  -V*  V*  o 


Aunm  s 

ETHERHET  SOFT HIRE  PBOTOCOL  SOURCE  CODE 


This  is  the  actual  source  code  which  is  developed  to 
■eet  the  principal  gcal  of  this  thesis.  This  program  is  also 
available  in  VAX/VHS  public  user  account  under  file  name 
"ETHERNET. FCR». 


PROGRAM  ETHERNET 


ACTUAL  RECEIVING  OF  MESSAGE. 

SEND  BACK  ACKNOWLEDGE  *SG.(2nd  tyoe  field=FF  hex). 

IF  RECEIVED  BAO  FRAME,  DO  NOTHING  BUT  WAIT  TO  RECEIVE. 
CHECK  WHAT  IS  THE  REQUEST  FROM  MDS  SYSTEM. 

IF  THE  REQUEST  IS  ’9'*  CALL  UPLOAD. 

IF  THE  REQUEST  IS  '  1  '  #  CALL  DOWNLOAD. 

character*2S  msql/'  Receive  successfully.  *'/ 

character*28  msa6/*  Unrecognized  file  tyoe.  *'/ 

inteqer*2  i osb ( 2 ) •  f i 1 t yoe , exec 

inteqer*^  systime(2)»  time(2) 

integer**!  nichan,  svs$gioe>  sysTassi  an 

include  '«-draO:tnossvs.interlanlnidef.for' 

include  '(Biodef)' 

byte  oad( l 00  ) 

byte  Roac  Vet  (  1  SO  ) ,  Tnac  feet  ( 1  36 ) 

byte  dfilnam(*!0)»sfiloam(N0),ft(3) 

Assign  a  channel  to  0 1 A  0 : 

istat=sysBassiqn( ' N I  40  ' »nicHani ,  ) 
i f ( .not . i st at  )  call  1 i b £ s t oo ( Zva 1 ( i s t a t  )  ) 

Start  uo  and  go  on  line: 

istat=  sys$ai ow( ,%val (nichan) , 

1  %val  ( i  o3«-set  mode  .or.  i  oSm*-st  ar  t  uo ) , 

2  i OSb  t  t  •  r  t  •  •  •  ) 

i f ( .not . i st at  )  call  1 i bSs t oo ( Xv a  1 ( i s t at )  ) 
i f ( i osb ( 1 ) .  1 1 . 0  )  call  1 i b 1st oo ( Zva 1 ( i oso C 1  ) )  ) 

Receive  incoming  message: 

tyoe  *,'  Ready  to  receive  message . ’ 

istar=sysSaiow(»2val fnicKan), 

1  Zval  ( io5«*readlbl  k) , 

2  i osb  » *  t 

3  Xref (Roacket ) >%val ( 150) , , , , ) 
i f ( .not . i st at )  then 

tvoe  *,'  Istat  receive  error' 
goto  10 

end  i  f 

i f ( i osb ( t ) • 1 1 . 0 )  then 

tvoe  *,'  VAX/VMS  receive  error' 
goto  10 

end  i  f 

i f ( i osb(2) .ea. I )  then 

tyoe  *,'  Receive  block  CRT  error' 
goto  10 

end  if 

i f ( i osb ( 2 ) . ea. 2 )  then 

tvoe  *  t  '  Receive  block  alignment  error' 
goto  10 

end  i  f 

i  f  ( i  osb  ( 2  ) .  ea .  *! )  then 

tvoe  *,'  Missing  receive  block' 
aof  o  1 0 

end  i  f 

i f ( i osb ( 2) .ea . 1 7 )  then 

tyoe  *,'  DMA  received  block  fail' 
goto  10 

end  i  f 


94 


p- lvx; 

•j 

■j 


r: 


k 


c 

c 


tyoe  *»•  deceived  successfully. 

Assign  destination  address: 
t Dacket C 1 )  =  1 02*  x 
Toacket C2)  =  ' 0  7  ’  x 
T  oacket C  3 )  =  '  0  l ' x 
Toacket ( 4 )  = ' 00  *  x 
Toacket (5)=Roacket  C IS) 

Toacket C6)=Roacket C 16) 

Send  acknowledge  message: 


Assign  type  field: 
Toac  k et  C  7 )  =  1 0 0 ' x 
Toac ke t  C 8 )  =  ' FF ' x 


1  indicate  that  it  is 
1  acknowledge  signal 


a  message 


Put  data  into  transmit  oacket: 
i=9 

do  i = 1 t 30 

FoacketCj)=ichar(msol(i:i )) 
i  =  i  + 1 

end  do 

Transmit  oacket : 

istat=sysSoiowC*%val f  n i c  h  an ) , 

1  ^vaiCioi+writelblk). 

2  i osb $ t  t 

3  ?re f ( Toac ket ) t X v a  1  ( 1 36 ) >  , , , ) 

i f ( i osb C 1 ) . 1 1 . 0 )  call  1 i bSs t oo ( £va 1 f i osn ( 1  ) ) ) 
type  Acknowledge  is  beina  transmitted.... 

Load  transmit  data  and  send: 

istat=sysSgiow(»%val Cn i chan ) , 

1  tval  (io^ltds)! 

2  i OSb  rrtrtttr) 

i f ( i osb ( 1 ) . 1 t . 0 )  call  1 i btstooCXval C i osb C 1 ) ) ) 
if(iosbC2).ne.O)  call  Tib$stoo(%vaiCioso(2))) 


Print  out  incominq  message: 
i  =  1  9 

if((Roacket(i).ea.ichar(' ' 

1  CRoacket ( i ) .ea. i char ( 

do  while  CRoacket ( i 
i  =  i  1 1 
sfi lnam(i-19)sRoacket(i ) 
dfi lnam(i-19)=Roacket(i  ) 

end  do 


)  )  .  o  r . 

5 ' ) ) ) t  hen 

J.ne.icharf*/' 


)  ) 


1 

2 

3 

a 

s 


i f(( CRoacket Ci-3).eo.icharC '  e ' 
.or.CRDacketCi*3).eQ.icharC’E' 
.and.C  CRoacket  C i  -  2 ) .eg.icharC ' 


.or . 

.  and . 
.or. 

else 


CRoac  ket ( i -2 ) 
C  C Roac ke t  C i - l ) 
CRoacket  C i - 1 ) 
exec  =  2 


ea 

eo 

ea 


end 
m  s 
do 


f 

tl 


exec  =  l 


i  char  ( 
i  char  C  ’ 
i  char  C  ’ 

:  E00 

1  o  t  he 


)  ) 

)  )  ) 
o’  )  ) 

O'  )  )  ) 
d'  )  i 
O’  )  )  )  ) 
exec  fi 


then 
1  e 


i 

i 

while  ( Roac k e t C m ) . ne . i c h a r ( 
ft  Cm-i )=Roacket  Cm) 
m  =  mt  1 


<ec  tiie 


)  ) 


& 
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<D-fli33  699  DESIGN  AND  IMPLEMENTATION  OF  SOFTWARE  PROTOCOL  IN  2/2 

VflX/VMS  USING  ETHERNET  LOCAL  AREA  NETWORK(U)  NAVAL 
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F/G  17/2 


UNCLASSIFIED 


NL 


MICROCOPY  RESOLUTION  TEST  CHART 

NATIONAL  BUREAU  OF  STANDARDS*  1963-A 


else 


end  do 

if  ( ( f t ( 1 ) .ea. i char ( ' t ’ ) ) .or . 
t  ( ft (1 ) .eq. i chart ’ T ')) )  then 
f i 1 1  voe  =  1 

else  if  t t ft t 1 ) .ea.ichart 'e' ) ) .or. 

I  t f t ( 1 ) .ea. i char ( ' E ' ) ) )  then 

f i 1 1  yoe  s  2 
e  1  se 


cal  1  sendmsgtRoacket  ( IS)  »3oacic?t  ( 16) # 
tvoe  *#*  Unrecognized  file  tyoe. '  ♦ 


nstjo ) 


goto 
end  i  f 


150 


do 


<^hileC^lDacket(i).ne.ichar(,*,)) 
i  =  i  *1 

end  do 

end  i  f 

write(6»ll)(Roacket(i)#isl0»i-l) 
fornat ( 1  '  #  <  i  >  a  1 ) 


Check  the  reauest  nessaqe: 

if  (Roac ket ( 1 9 ) . ea. i c ha r C ' i * ) )  then 
s  f i 1 nam ( i - 1 9 ) =0 

call  down load(9oacket(t5)#RDacket(lb)»sfilnam, 
1  f i 1 1  yoe » exec ) 

else  if  C 9oac ket ( l 9 ) . eq. i c har ( ' H ' ) )  then 
dfi1nam(i“19)=0 

cal  1  uoload(Roacket(15)»Roacket(16)fdfi Inam# 

1  f i 1 1 voe#  exec ) 

end  i  f 
goto  10 


nnnn 


SUBROUTINE  DOWNLOAD ( r 1 5#  r 1 6»  s f i 1  nan »  f i 1 t  yoe »  e xec ) 


C 


C 

C 

22 


C 


C 


c 


c 


ACTUAL  transfer  FILE/INTERACTIVE. 

RETRANSMIT  SAME  FRAME  IF  NOT  RECEIVE  ACKNOWLEDGE  IN  S  SEC. 
ABORT  TRANSMISSION  IF  NOT  RECEIVE  ACKNOWLEDGE  IN  10  SEC. 


character*?? 
charac  t  er  *2? 
i nt  eger  *2 
i nt  eqer *2 
i  nt  eger  *  £1 
i nt  eger *4 
i nteger*a 
i n c 1 ude 
include 
byte 
byte 
byte 


•nso2/'  No  such  file!  Try  again.  *'/ 

nso3/'  Abort  T  r  ansu  i  ss  i  on .  *'/ 

iosb(2)#addr,count#done 

f i 1 1  yoe»exec  »na« 

nichan»  sys$oio*»  syslassiin 

sysSbintim,  sys Tset i nr »  sysSwai  tfr 

t i ne ( 2 ) »  sy st i ne ( 2 ) 

'  «-dr  a0 :  Inossys.  inter!  anl  nidef.for' 

' ( $ i ode  f  ) ' 

oadClOO) »sendrec (512) » sen dree  1  ( 102a) 
Toacket  (1 36 ) »  s  f  i 1  nan ( U0  ) 
Roacket(150),rt5,rl6 


Assign  a  channel  to  NI40: 

istat=sysiassiqn( 'NIAO' , n i c  han , ,  ) 
i f ( .not . i st at )  cal!  1 i b Ss t oo ( %v a  1 C i s t a t ) ) 


Pr i nt  out : 

tyoe  *»’  Reauest  transferring  of  file' 


Print  f i 1 ename  S 

write(6#22)(sfi  lnan(k)»ksl,15) 
f ornat  ( '  ' ,  1 5a  1 ) 

tyoe  *»  '  to  MOS  systen  at  address:02  07  01  00'r 
1  r 1 5, r  1  b 


Assign  destination 
T oacket ( 1 )  =  ' 02  '  x 
Toacket (2)=' 07' x 
Toacket (3)='01 *x 
Toacket (a, s' 00'x 


address : 


Get  the  address  of  requesting  station: 
Toacket ( 5 ) =r l 5 
Toacket  C 6 ) =r 1 b 


Assign  tyoe  field: 

T oac  ket  C  7 ) a • OF  *  x 

Toacket (8)  =  ' 00  '  x  !  first  *rame 

Initialize  f 1 aq: 
done  =  0 


C 

C 


Ooen  file: 

ooen(name=sfilnan  runit=l*organizat ion-sequential 
1  »tyoe='old'rcarri aaecont  rol  =  'list'rerr=9) 


Pile  tyoe  check  ooint: 

if  (  f  i  1 tyoe.ea. 1 )  then 
goto  30 


else 
end  i  f 


goto  200 


Ooen  file  error  handlinot 

call  sendmsg(rl5#  rlb,msq2) 
tyoe  *»'  no  such  file!  Try 
return 


such 
aaa i n . * 


no 


file  try  a  ga  i  n 


Send  text  filet 
count  =0 

read( 1 , 33, i ostat 
1  ( Toacket  (  i ) , 

f ornatC  1 28a  1  ) 
Toacket ( 1 55)  =  ' 
Toacket ( 1 56)  =  ' 

1  st  at  =svsiqi ow ( # 
1 

2 
5 

if (iosb(l).lt.O) 
i f ( i osb (2 ) ,ne . 0 ) 
t  yoe  *  t  '  File  is 


=  ios*end=109,err=101  ) 
j=9,13b) 


0 A ' x  1  <CR> 

00 ' x  1  <LF> 

X  va  1 (nichan)r 

Zval  (io?«-writelblk), 

i  osb#  * , 

Xref(Toacket)»Xval C 1 3b) , , ,  ,  ) 
call  1  i  b?stoo( Xva I ( i osb ( 1 ) ) ) 
call  1 i bSst oo ( Xva 1 ( i osb (2 ) ) ) 
being  transmitted . ' 


Load  transmit  data  and  send  filet 
istat=sysioiow(,Xval (nichan), 

1  Xva  1  ( i  o*-«- 1 1  ds  )  # 

2  i osd , , ,  t  f t  >  •  ) 

i f ( i osb ( 1 ) • 1 1 « 0 )  call  I ib*stoo(Zval (i osb(  i ) ) ) 
i f (iosb(2) .ne.O)  call  1 i b$st oo ( Xva 1 ( i osb ( 2 ) ) ) 


aait  for  15  seconds  and  abortt 

istat=svs$bintim('0  :tl5.0*,time) 
i  f (  .not . i st at )  call  1 i bf stoo ( Xva 1 ( i st at ) ) 
istatssys$setimr(Xval(2)»Zref(time)»») 
i f (  .not . i st at )  call  1 ibSstoo( Xval ( i st at ) ) 


Alait  for  5  second  and  retransmitt 

istat=svs$bintim('0  ::5.0'#svstime) 
i  f ( .not . i st at )  call  1 i bSstOD ( Zval ( i st at ) ) 
i3tat=svsisetimr(Zve)(l)/Xref(svstime)f>) 
i f ( .not . i st at )  call  1 ib$stoo(Xval (istat ) ) 


wait  for 
5  sec  . 


deceive  ac know  1  edge t 

istat=svs3qiow(*Xval (nichan) , 

1  Xva 1 ( i oS^read 1 b 1 k  ) , 

2  iosOfM 

3  Xre f (Roac <e t ) t X va 1 ( l 50 ) , , , , ) 

i f ( i osb ( l ) . 1 t .0 )  call  1 ibSstoo(Zval ( i osb( 1 ) ) ) 
i f (iosb(2) .ne.O)  call  1 ibSstoo(Xva1 ( i osb(2) ) ) 


Check  the  second  tyoe  field  if  =  FF  hext 

if  (Roac ket ( 1 8 ) . ea. ' FF ' x )  then 

call  sys Scant i m (,  )  !  cancel  timers. 

poac ket ( 1 9 ) a ' 00  * x  !  clear  flag 

i f (done.eo. 1 )  goto  50 
Toac ket ( 9 ) = 1 0 1 ' x  !  middle  frame 

aoto  30 

end  i  f 

if  (count. ne. 2)  then 

call  sy s Swa i t f r ( Xva 1 ( 1 )  ) 
count  scount ♦  1 
qoto  40 

end  i  f 

call  sy sSwai t f r ( X va 1 ( 2 ) ) 


call  sendmsg(rl5,rlf>,msg3)  ,  1  a°ort  transmission 

tyoe  *i 1  Abort  transmission, 
return  , _  . , . 

call  1 ib$stoo(Xval ( i os) ) 

Assign  value  to  message  of  the  last  frame: 

do  l^aclte(.(  j  )  =  •  32  •  X  !  blank  char 

Toacket(9)='FF‘x  •  1  as t  f  ram® 

done  •  1 
goto  40 

Send  executable  files 

if  (exec .eg. 1 )  then  #  caa  »  a  a  a  \ 

read(l»222#iostat=ios,  end- SO  0 , er r-2  0  2 ) 

1  ( sendrec ( i ) / i = 1 » 5 1 2 ) 

f  grmat ( 5 1 2a 1 ) 
max  =  5  L 

else  if(exec.eg.2)  then 

read( 1 , 333» i ostat =i ps * end  =  S0 0 , ® r r-?0 2 ) 

1  ( sendrec 1 ( i ) # j  =  1  *  1 024 ) 

f  o mat  ( 1  024  a  1 ) 
max  =  9 
end  i  f 
k  =  1 

5?UTSS1?U8 

* f  *  Tpae  ice?  ( 1  *=n  sendrec  (kM28-(l?9-U) 

else  if  (exee.ea.2)  then  .. 

end  i  f 

i  stat=svs$qio«( /Xval (nichan)# 

1  Xval  (ioS«-writelo1  x) » 

f  I ref ( foacket ) , *val (1 36 ) , , » » ) 

if (iosto(l).lt.O)  call  libSstoo  Jva  iosd  1 
i  f  ( i  osb  (2)  .ne.O)  caU  1  i  bSs t oo (  2val  ( i  oso  (  2) ) ) 
tyoe  *»’  File  is  being  transmitted . 

Load  transmit  data  and  send  file: 
istatssysiaiow(»Xval (mchan)» 

1  Xval  ( i  o*"*"l  tds  )  t 

if  (iosb(l).lt.0)121?rj  joist  oo  (%val  (iosb(l))) 

i f ( i osb (2). ne.O)  call  1 i bSs too ( ival ( i oso ( 2 ) ) ) 

dait  for  15  seconds  and  abort: 

istat^sys-Sbintimf  O  ::l5.0»time) 
if (.not.istat)  call  1 i bSst ooCXval ( i st at ) ) 
istat=sysSsetimr(%val (2)»Xref(time)»» > 
i f ( .not . i st at )  call  1 i bist oo( %val ( i st at ) ) 

<»ait  for  5  second  and  retransmit: 

istat=sys3bintim('0  : :5. 0 • , svst i me) 
i f ( .not . i stat )  call  1 i b i s too ( Iva 1 ( i s t at ) ) 

istatssys$setimr(Xval(l)»iref(svstime)»»)  .  wait  for 

i f ( .  not . i st at )  call  1 i o $s t oo ( Sva 1 ( i st at ) )  1  5  sec. 
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*4 


< 


1 


20  2 
C 

500 


50 


cancel  timers. 
1  clear  f 1 ao 

i  middle  f rame 


Receive  acknowledge:  . 

istat=sysSqioww%val (nichan), 
t  %val ( loiereadlbl k) , 

\  X  ref ( Roac We t ) , %va 1 ( 1 50 ) » t j » ) 

i f(iosb(l).lt.0)  call  1 ibSstoo(%val  ioso  1 ) 1) 
i f ( i osb(2) .ne.O )  call  1 i b »st oo( *va 1 ( i oso C 2 ) ) ) 

Check  the  second  tyoe  fi©ld  ’f  =  FF  he*: 

if  (Roacket ( 1 3) .ea. *F5 1 x )  then 

cal  1  systcant im(#  ) 

Roac  ket (l8)='00'x 
i f (done . ea • l )  goto  50 
Tdsc  ket ( 8 ) s ' 0 1  'x 
k  =  k  1 1 

if  ( k .ed.ma* )  t  hen 
got  0  20  0 
e  1  se  _  ,  , 

a  o  t  o  30  0 

end  i  f 

end  i  f 

if  (count. ne. 2)  then 

call  svs?waitfr(%val (1)1 
count  =count ♦ 1 
goto  400 

call  svsSwaitfr(%val(2)) 

call  3endmsq( r 15» r 16,msp3)  i  aOort  transmission 

type  *»'  Abort  t r ansmi ss i on . ' 

return 

call  1 i b$st oo (Xval ( i os ) ) 

Assign  value  to  message  of  the  last  frame: 

do  i "9r 1 joacket ( i )='32' x  l  blank  char 

fSacket<8)s'FF'x  !  last  frame 

done  =  l 
goto  400 


/oe 


c lose (units!) 
return 
end 


Transmit  comoleted' 


■j* 

9 
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nnnnnnn 


SU8R0UTIME  UPL0AD(rl5»rl6,dfilnam,filtyoe,exec) 


ACTUAL  RECEIVING  OF  FILE. 

DISCARD  LAST  FRA«E. 

CHECK  FOR  1  RECORD  FILE. 

SEND  BACK  ACKNOWLEDGE  MSG.(2nd  tyoe  field=FF 
IF  RECEIVE  BAD  FRAME ,  DO  NOTHING  BUT  WAIT  TO 
SAME  FRAME  AGAIN. 


hex  )  . 
RECEIVE 


character*23 

character*29 

c*ai*aeter*28 

i nt  eqer*2 

i nt  eaer *4 

i nc 1 ude 

include 

bvts 

byte 

byte 


msat/'  Received  successfully.  *'/ 

msa4/'  Ooen  file  fail!  Try  again.’  '  / 
msg5/'  Tyoe  "sendfile  FN.FT".  *•/ 

ioso(2), done, fi)tyoe»exec, max 
nichan,  sysSgi ow>  s vs Sass i an , rec s i ze 
1  «-draO :  [nossvs.interl  anl  nidef.for' 

' (Siodef ) ' 

oad  (  iOO  )  ,  getrec  (St?)  ,  oet  rec  t  (  10  24) 
Roac  ket ( 150) ,  d  f  i In am (40) 

Toac k et ( 1 36 ) , r 1 S ,  rlo 


Assign  a  channel  to  NIAO: 

istatssysSassianf’NIAO'^nichan##) 
i f ( .not . i st at )  call  1 i b Sst oo ( %v a  1 ( i st at ) ) 

Print  out i 

tyoe  Reauest  reeeivina  of  file* 

Pr i nt  f i 1 ename : 

write(S#44)(dfi1nam(lc),k  =  l,15) 
f ormat ( '  '  ,  1 5a  1  ) 

tyoe  *i ’  from  MOS  system  at  address:  02  07  01  00', 
1  r 15, rib 

Initialize  flag: 
don e*0 

Determine  record  size  ov  file  tvoe: 
if  ( f i 1 tyoe.eq. 1 )  then 

recsize  =  12B  1  text  file 

else  if  (exec.ea.l)  then 

recsize  =  512  1  executable  file 

max  =  5 

else  if  (exec.ea.2)  then 


end  i  f 


recsize  ~  102a 
max  =  R 


I  EOD  exec  file 


Ooen  new  file: 

if  ( f i 1 t yoe.eo.2)  then 

ooen(name=dfi lnam,uni t  =  ? , 

1  orqani zat i on= ' sequent i a  1  ' , 

2  tvoes'oew',carri aoecont rg 1 s ' 1 i st  * , 

3  i os t a t = i os , er r=7 , 

4  recordsize=recsize,recordtvoe='fixed') 
el  se 


t 

2 

3 

end  i  f 


ooen(name=dfi lnam,uni t  =  2 , 

oroanization='seauential ', 
tyoe=*new ' ,carri agecontrnl  =  ' 1 i st  * , 
i ost  at  =  i os , er r  =  7 ) 
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7 


C 

90 

20 

55 

C 

C 

60 

C 

C 

C 


goto  90 

call  sendmsg(rl5,  rt6#msg4) 

tyoe  *#'  Ooen  file  fail;  Try  again’ 

return 


Recei ve  file: 

call  sendmsg  ( r  1 5  #  r  1 6 ,  Tisg5 ) 

type  Send  instruction  message. 

type  *#'  Beady  to  receive  file . •  * 

k  =  1 

istat=sysSgiow(#%val (nichan), 

1  tval  (  i  o*«*readl  b  1  k  )  , 

?  i osn » >  t 

3  X re f  ( Rose  ke t ) » tva  1  ( 1  50  ) , , ,  »  ) 

i f ( i osb( t ) . 1 1 .0)  call  1 i bSst oo ( Xva I ( i osb ( t  )  )  ) 
if(iosb(2).ne.O)  call  libSstoo(%val(ioso(2))) 
if  (Rgacket ( 18) .eo. ' OF ’ x )  t«en  1  a  1  record 
write(2»55)  (°oacket  ( j  )  t  i  =  1 9 ,  1  d  6 ) 
format ( 1 28a 1  ) 
done: 1 

else  if  CRoacket ( 1 81 ,eo. * x )  then 
done* 1 


file 


Send  acknowledge  message: 

Assign  destination  address: 
T  packet ( 1 ) s ' 02  '  x 
T packet ( 2)  =  ' 0 7  '  x 
T packet ( 3) *  0  1 'x 
Toacket (a )s ' 00 ’ x 
T packet ( 5 ) sr 1 5 
Toacket (6)=r 16 


Assign  type  field: 
Toacket(7)=  00’x 
Tpacket (8)s 'FF • x 


1  messaae 

1  acknowledge  signal 


Put  data  into  transmit  oac*et: 
j=9 

do  i = l »  28  ... 


end  do 


Toacket ( j )  =  icHar(msql (i  :  i  ) ) 
is)*i 


T ransmi t  packet : 

i st at =sys3gi ow C , %va 1 ( n i chan ) , 

1  Xval  (io5**writelblk), 

2  i osb, , , 

3  X  ref ( Toac ke t ) , %va 1 ( 1 56 ) , , , , ) 

i f ( i osb ft ) . 1 1 . 0 )  call  l i b ?s t go T %va 1 ( i oso ( 1 ) )  ) 
if(iosb(2).ne.O)  call  iib£stoo(3val(iosb(2n) 
type  Acknowledge  is  being  transmitted.... 

Load  transmit  data  and  send: 

i statssys So iow(,%val (nichan), 

1  %val(io**ltds)» 

2  iosb ,,,*»*,»)  ,  .  ,  . .  . 

if(iosbCl).lt.O)  call  libSstoo(Tva  (iosti(l))) 
i f ( i osb(2) .ne.0)  call  1 i b5s t on ( X va H i oso ( 2 ) ) ) 
if  ((done. eg. 11  .and.  (k.ne.max)  .and. 
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^  ***** 


1  ( f i 1 t yoe.ed.2) .and.  (exec.eq.l))  then 

write(2,555)(getrec( i ), i  =  1,(128* (k-l) ) ) 
goto  70 

else  if  (done.eq.l)  then 
qoto  70 

end  i  f 

rtrite  to  record  every  after  receivina  '4  or  *  frames: 

if  ( f i 1 t yoe  .  eo. 2 )  then 
do  1sl#12fl 

i f  (exec.eo. 1 )  then 

getrec(k*128-(  128-1  )  )=Roacket  (1  +  18) 
else  if  (exec.eq.2)  then 

aetrecl(k*128-(128-l))=Roacket(l+18) 

end  i  f 
end  do 
k  =  k  + 1 

if  ( k .en.max )  t  hen 

if  ( e  x  ec . eo .  1  )  then 

write(2,S55)(qetrec(j)fj=l>recsize) 
format (51 2al ) 
else  if  (exec.eq.2)  then 

write(2»777)(qetrecl(j)»i=lrrecsi2e) 
format  ( 1  02'4a  1  ) 
end  i  f 
k  =  1 
end  i  f 

else  if  ( f i 1 t yoe . eq . 1 )  then 

write(2,666) (Roacket ( j ) , i  =  1  R »  146) 
format ( 1 28al ) 

end  i  f 

goto  20 

c 1 ose ( un i t=2) 

type  *»  '  Receive  comoleted!' 

return 
d 


3 


SUBROUTINE  S£NDMSG(rl5,r16,mSq) 

ACTUAL  SENDING  OF  MESSAGE. 

« A  I T  FOR  ACKNOWLEDGE. 

IF  NOT  ACKNOWLEDGE  IN  5  SEC,  RETRANSMIT. 

IF  NOT  ACKNOWLEDGE  IN  10  SEC,  ABORT  TRANSMISSION. 


Character* ( * ) 

i nt  eaer *2 

i nt  eaer*a 

i nt  eaer *4 

i nt  eber*4 

i nc 1 ude 

include 

byte 

byte 

byte 


msa 

iosb(2)»addr,done,count 
nichan,  sysJaiow,  sysTassion 
sysSbintim,  sysBsetimr,  sysSwaitfr 
syst i me ( 2 ) , t i me ( 2 ) 

'«-draO:(nossvs.interlanlniqef.for' 

' ( 5 i ode  f 1 ' 
oad ( 1 00 ) 

Toacket  ( t  56) ,  text  ( 128)  , Roac  ke r  ( ISO) 
r  1  5  *  r  1  6 


Assign  a  channel  to  NIAO: 

istet=sysSassiqn( 'NIAO' , nichan,  ,  ) 
i f ( .not . i stat )  call  ) i b Ss t on C % y a  1  ( i s t at ) ) 


Assign  destination  address: 
T  oac  k  et ( 1 ) s ' 02 ' x 
T packet ( 2) s 1 0  7 • x 
Toacket (  3 )  = '  0  1 '  x 
T oac  k  e t (  4 ) a *  0  0 ' x 
T  oac  ket ( 5 ) sr  1  5 
Toacket (6)=r 16 

Assiqn  tyoe  field: 

Toacket (7)='00’x  i 

ToaC ket ( 8 )  =  ' 00  '  x  1 


messaae 
don't  care 


Put  data  into  transmit  oacket: 
jsR 

do  i=l,28 


end  do 


Toacket! j )=ichar(msq(i :i )) 
J  =  itl 


Transmit  oacket: 
count  =0 

istatssvs5qiow(,Xval (nichan), 

1  %va I ( i oJ*wr i t e ? b 1 k  ) , 

2  i osb, , , 

3  Zref ( Toac ke t ) , %va 1 ( 1 36 ) , , , , ) 

i f ( i osb ( 1 ) . 1 1 .0 )  call  1 i b$st oo (tva 1 ( i osb ( 1  ) ) ) 
i f ( i osb(2) .ne.0)  call  1 i b5 s t oo ( Zva 1 ( i osb ( 2 ) ) ) 
tyoe  *,'  Me53aqe  is  beinq  transmitted . ' 

Load  transmit  data  and  send: 

istat=sys3qiow(#%va1 (nichan), 

1  Zva  1  ( i  o+’+’l  t  ds )  # 

2  i osb ,,,,,,,,  ) 

i f ( i osb ( 1 ) . 1 1 . 0 )  call  1 i b Bstoo( %va l ( i osb ( l )  ) ) 
i f ( i osb ( 2 ) ,ne . 0  )  call  1 i bSst oo (%va 1 ( i osc ( 2  ) )  ) 


Wait  for  15  seconds  and  abort: 

call  sysibi nt i m ( ' 0  : : 1 5 . 0 ' , t i me ) 


call  svsfsetimrCXval  (2)»Xref(time)r») 

sait  for  5  second  and  retransmit: 

call  sys$ointim('0  ::5.0'#systime) 

call  svs$setimr(%val  (l)»%ref(svstime)»»)!retransmit 

1  af  t  * r  5  sec 

Receive  acknowledge: 

istat=svsSgiow(#%va1 ( ni chan ) , 

1  %  va  1  ( i  o$«*read  1  b  l  k  )  # 

2  i osb  t , , 

5  %ref (Rpacket ) # tval ( 150 ) , , , , ) 

if(iosbd).lt.O)  cal?  I i b ?s t oo ( X va l( i oso(l ) ) ) 
i f ( i osb (2) .ne • 0 )  call  1 ibSstoof Uval (ioso(2) ) ) 

Check  the  second  tvoe  field  if  =  FF  hex: 
if  ( Roac ket (t 8 ) . eg . 1 FF • * )  then 

i  =  1 R 

do  while  ( Roac ket ( i ) . ne . i c har ( • *  1 ) ) 
i  =  i  +  t 

end  do 

write(6»66)(Roacket(j)»i  =  l<,#i-l) 
format ( '  ' #  <i >a  l  ) 

call  sys$cantim(  »  )  !  cancel  timers 

Roacketfms'OO'x 

return 

end  i  f 

if  (count. ne. 2)  then 

call  sysf wai t f r (?val d ) ) 
count  scount ♦ \ 
goto  80 

end  i  f 

call  svsSwai tf rCXval (2) ) 
return 


It 


a  uum  s 

IAX/1HS-HDS  ETHERNET  LOCAL  COBiUEICATION  NETHOBK  USER  MANUAL 


GENES 1L: 

ETHE5NET  is  a  prograa  that  will  allow  an  individual  tc 
transfer  a  aessage  cr  a  file  between  VAX/VNS  and  the  BDS 
Systea.  After  this  prograa  is  executed  on  one  of  the  VAX/VNS 
terainals,  a  user  can  leave  the  terainal  and  operate  only  on 
the  NES  Systea  terainal  until  he  wants  to  disconnect  the 
coaaunicaticn. 

The  user  can  execute  this  prograa  only  when  be  has 
LOG  IC  privilege*  If  any  probleas  occur  while  executing  the 
prograa,  user  can  contact  one  of  the  following  VAX/VNS 
professional  staff: 

Albert  Hong,  Sp505,  x2455 
Olive  Paek,  Sp525b 
Jeanne  Bowers,  Sp525a,  x2168. 


SPECIFIC: 

ETHEBNET.EXE  prograa  resides  on  the  VAX/VNS  under  public 
user  acccunt  with  user  naae  "INTEBLAN"  and  password  NVHSn. 
Any  user  can  copy  this  file  by  typing  in  the  following 
coaaands: 

JCopy  <CH> 

SFrca:  vdza1 :[  interlanjethernet.exe  <CB> 

$To:  *  <CR> 

The  user  should  also  copy  file  ETHER1.EXE  which  should 
be  executed  after  finishing  the  file  transfer  process  in 
order  to  clear  both  transait  and  receive  buffers. 


Shen  these  two  files  are  copied,  user  can  execute 
ETHERNET. EXE  by  typing 

ir  ethernet  <CR> 


then  the  aessage 


Beady  to  receive  aessage. 


will  appear  cn  the  screen  which  tells  the  user  that  VAX/VHS 
has  teen  connected  to  the  Ethernet  Local  Area  Network. 
After  this  point  the  user  can  do  any  file  or  aessage 
transfer  by  working  on  the  BOS  System  terminal. 

2EM1II2S  on  mds  SX53|B: 

At  the  tiae  this  thesis  is  being  written,  there  are  2 
diskettes  which  contain  prograa  used  to  do  file  and  message 
transfer  between  BDS  Systea  and  VAX/TBS,  one  diskette  is  to 
be  used  with  the  BOS  Systea  which  is  connected  to  the  single 
density  disk  drive  and  it  contains  the  following  programs: 

LOGON1.COH 
SEN  DBS G1 .COB 
SEN DPT Li. COB 

the  other  is  to  be  used  with  the  BDS  Systea  which  is 
connected  tc  the  double  density  disk  drive  and  it  contains 
the  fcllcwing  programs: 

L060N2.  COB 
SENDHSG2.COM 
S  END  FIL2  .COB. 

These  twc  diskettes  are  now  being  used  by  Capt.  Hark  Srctzer 
OSHC,  the  originator  of  the  programs  in  the  diskettes. 
Therefore,  the  final  instructions  on  how  to  use  the  programs 
will  be  found  in  his  thesis  which  will  be  completed  by 
Septeaber  1S83.  However,  the  instructions  on  how  to  trans- 


fers  file  cz  messages  between  the  MDS  Systea  and  VAX/VMS  are 
as  fellows: 

When  the  systea  is  booted  up  with  the  above  mentioned 
diskette,  execute  LOGGN1.COM  (or  LOGON2.COM  if  you  work  with 
the  dcuble  density  disk  drive)  by  typing 

A>L0G0N1  <CR> 

To  tr$ns»;Lt  a  message  from  the  UPS  System  to  the  VAX/VMS: 
A>SEBDHSG 1  <CB> 

ETHERNET  CONSOLE  MESSAGE  TRANSMIT  PROGRAM: 

VERSION  1.11-SINGLE  DENSITY:  06/10/83-MDS 

NOTE:PBOGRAH  "LOGON  1"  HOST  BE  LOADED  PRIOR  TO 
RONNING  THIS  PROGRAM  FOR  PROPER  OPERATION. 

IF  NOT  -COLD  BOOT  AND  TYPE  "LOGON  1"  AND 
THEN  INVOKE  THIS  PROGRAM. 

SELECT  NET  ADDRESS  OF  DESTINATION: 

ADDRESS  00- 04-0 A (  HDS  SYSTEM  )  : E NT E£  1 
ADDRESS  00-03-E A  (  MDS  SYSTEM  ):  ENTER  2 
ADDRESS  00-07-7F  (  VAX  11/780  )  : ENTER  3 

3 

INPOT  MESSAGE  (128  CHAR  MAX)  -END  HITH  ACCENT=>  ' 
gqt^x  message  ^eje.  ^ 

SENT 

A> 

10  tijjsiit  a  liis  II ££  22 31  h  4isjc  to  VAX/VMS: 

Initiate  SENDMSG  like  you  want  to  transmit  a  message  as 
above.  Eut  this  tiae  you  must  enter  the  special  message  as 
shown  belcw: 

A>21i£l!£21  <£fi> 
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INFUT  HESS  AGE  (128  CHAR  MAX) -END  WITH  ACCENT»>  * 

Mi  Mb  sag  •  lilsliESZisll 

SENT 

**********  RECEIVED  MESSAGE  IS: 

Type  "sendfile  EN.FT" 

**********  END  CF  MESSAGE 

CCNNEC1ED  TO  THE  ETHERNET-COLD  BOOT  TO  DISCONNECT 

*>Sj*J2mi  filename,  filet  ype  <£R> 

ETHERNET  FILE  TRANSFER  PROGRAM: 

VERSION  1.12-SINGLE  DENSITY  :  06/10/83-MDS 

HOTEiFCR  PROPER  OPERATION,  PROGRAM  "LOGON1 M 
HOST  BE  EXECUTED  FIRST  TO  LOAD  THE  INTERRUPT 
HANDLER  INTO  MEMORY.  IF  HOT-COLD  BOOT  AND  DO  SO 

SELECT  NET  ADDRESS  OF  DESTINATION: 

ADDRESS  00-04-0  A  (MDS  SYSTEM)  : ENTER  1 
ADDRESS  00-03-EA  (MDS  SYSTEM)  : ENTER  2 
ADDRESS  00-07-7F  (VAX  11/789)  :ENTER  3 

•a 

IS  IBIS  A  TEXT  FILE  [5  2.5KB  MAX]  (  Y  OB  N  )  »»> 

Y 

BEADING  THE  FILE  INTO  THE  BUFFER... 

READ  COMPLETE 

**********  FILE  TRANSFER  BEGINS  ********** 


**********  PILE  TEA  NS  PER  COMPLETED  ********** 


A> 

12  I £SSiZS  a  lii e  i£OM  UIZIM  IQ  22M  disk: 

Initiate  SENDHS6  like  you  want  to  transmit  a  message  as 
above.  But  this  tiae  you  must  enter  the  special  message  as 
follow: 

A>SENCHSG 1  <CB> 


INPOT  HESSAGE(128  CHIB  MAX)  -END  WITH  ACCENT*>  ' 


ifilesaae. 


SENT 


*****•«***  FILE  RECEIPT  BEGINS  ********** 
OPENING  RECEIVE  PILE:  RECFSOHX.NET 
BX 
BX 


*****  END  PILE  RECEIPT'S  EE  PILE  RECPROMX.NET  ***** 
CONNECTED  TO  THE  ETHEBNET-COLD  BOOT  TO  DISCONNECT 

A> 


Note:  Except  for  line  spacing ,  th6  above  sequences  appear  as 
they  will  at  the  HDS  System  terminal.  The  underlined  items 
are  those  which  you  must  enter  (in  proper  sequence)  . 


Important  nets: 

1) Do  not  forget  to  end  any  aessage  sent  to  the  ViX/VSS 
with  accent 

2) The  H/txt"  is  used  to  indicate  that  the  file  to  be 
transferred  is  a  text  file.  The  Vexe"  is  used  to  indicate 
that  the  file  to  be  transferred  is  an  executable  file.  User 
■ust  specify  this  indicator  correctly  to  yield  the 
successful  transferring  of  a  file. 


umm  s 

SYBBOLIC  BABB  VOB  III  010  COITBOLLBB  COHHAID  CODE 

This  ip  pad  iz  lists  all  NXDBIVEB  QIO  function  codes.  The 
HI 10 10  Ithernet  Controller  User  Banual  contains  a  coaplete 
description  of  the  NI1010  controller  coaaand  codes  and 
status  returns. 
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IPtBIDII  F 

■I  EBIT  EH  FUBCTIOB  AID  STATUS  CODE  SOBS AIT 

This  Appendix  lists  all  NIDBIVER  QIO  function  codes  and 
IOSB  status  codes  for  each.  The  list  of  IOSB  status  does  not 
include  standard  7AX/7HS  error  codes  for  dev  ice- independent 
errors. 

The  Mil 010  Ethernet  Controller  User  Manual  contains  a 
complete  description  cf  the  MI10 10  controller  coaaand  codes 
and  status  returns. 


ills  octal) 


IOJ  SETMODE! 
IOS1  STABTUP 
IOf  SET  MCE  El 
IOf  I  SHOIDOBB 
IOf  IEAD1ELK 
10$  BEADFBLK 
IOf- B BITE LB LK 
IOS— WBITEEBLK 
IO^SBILB 

10 _ SILH 

IOHdH 

10 — SFBM 

IO—CFBH 

10 — SBOEB 

IO~~CBOEB 

IO~*OFFLIHE 

IO~CllIII 

IO~~BOBD 

I0~BBS 

10 — BCD! 

IOHSBB 

I0~LTD 

I0“I1IDS 

I0~IG1 

IO"~DGA 

IO~FSBQ 

I0””BESET 


Go  Online 
Go  Offline 

Supply  Beceive  Buffer 
Supply  Beceive  Buffer 
Load  Trans  sit  Data  and  Send 
Load  Transait  Data  and  Send 
Set  Module  Interface  Loopback 
Mode 

Set  internal  Loopback  Mode 
Clear  Loopback  Bode 
Set  Prcsiscuous  Beceive  Bode 
Clear  Promiscuous  Beceive  Mode 
Set  receive-on-Error  Bode 
Clear  Beceive-On-Error  Bode 
Go  Offline 
Go  Online 

Bun  On-board  Diagnostics 
Beport  and  Beset  Statistics 
Beport  Collision  Delay  Time 
ly  Beceive  Buffer 
Transmit  Data 
Transait  Data  and  Send 
r  Grcup  Address (es) 

Delete  group  Address(es) 

Flush  receive  BAB/BCS  Queue 
Reset 


11  ,17 

ii:n 


0  (see  note 
0  (see  note  1f  , . 

0 ,1,3, 5,6, 10, 17 
0,1,3,5,6,10,17 

0 

0 

0 

0 

0 

0 

0 

0 

0 

See  note  2 
0,17 

o'w 

0  (see  note  1)  ,17 
0,5, 17 

2'2'?*5«§'10'17 

0,5,12, 

0 ,5, 12, 17 
See  note  2 


note  1:  The  STATUS  byte  of  a  received  packet  will  contain 

none  or  more  of  the  following  octal  error  codes: 


1  CBC  error 

2  alignment  error 

4  1  or  more  packets  were  previously  missed 

or  it  will  contain: 
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17  Mon-existent  eeeory  tiaeout  on  so* e  tuffer 
word  (other  than  the  first)  occurred  while 
DHAing  the  received  packet  into  aenory 

note  2:  The  second. JOSB  lcngword  at  the  coaple*ion  of  this 

ccaaana  will  contain  one  of  the  following 
diagnostic  codes: 

0  success 

1  checksum  error  m  local  aeaory 

2  MS  10  DMA  error 
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